How ASTA Compares to the World Wide Web

The World Wide Web (the "web"), and the servers and browser that make it work, are a fantastic and highly useful pieces of technology. But like all tools, the web has appropriate and inappropriate uses. Whether you entrust your business to a technology like the web or a technology like ASTA is a question of appropriate use.

We believe that the classic web architecture - a weight browser, the HTTP protocol like HTTP, and a (database-connected, if necessary) server - is the best way to handle many lightweight applications.

The page that you are reading right now is an example of an appropriate use of technology, the web is great for presenting read only data. Eventhough the technology that we created can perform this task, it is handled well by the WWW and is the better choice for publishing this page. But while the WWW is good for simple data, we feel that it is a poor choice for trying to implement complex applications, even with Java or ActiveX. The web seems particularly ill-suited for data driven, enterprise wide, business applications.

What's wrong with the web?

The problem with the web is fundamental to it's architecture and manifests itself in two places, the protocol and the interface:

• HTTP, the language between servers and browsers, is a stateless protocol
• HTML has a limited interface and limited utility

A "stateless" protocol is one where the connection is not maintained. Put simply, the web can't "push." Clients can ask the server for information, but the server cannot send send information to the clients. For instance, a customer might trade stocks using a browser on the Internet. But the brokerage notifies the customer that their stock trade has occurred by sending email. This is the result of an architecture built on a stateless protocol, the server cannot update the browser. While this is not a critical problem for a casual surfer, it is unacceptable in a business environment.

The second problem is the limitations of the Hyper Text Markup Language (HTML). At first, the web seems to have a rich interface . . . look at all the rich text, images, video and even audio! But the fact is that those same media can be readily delivered in business applications. They simply haven't been. Why? Probably because most businesses are more concerned with basic commerce than entertainment. Hopefully, as a result of the web, "regular" applications will become more lively without sacrificing their usefulness. But despite the varied media riches, HTML is not practical for business tasks. HTML has inadequate database support and interface tools. Would you want to use the web as your word processor or spreadsheet? No.

Web Burn

What is web burn? Web burn is our name for the phenomenon whereby well-intentioned teams set out to deploy a web based solution and they "fail." They typically produce a useful site, but one that is far short of intended use and functionality. Furthermore, the effort always costs much more and takes much longer than anticipated. There are good reasons for this! The web wasn't designed for complex applications, that's not an appropriate use. The web is great for simple applications, but it is terrible at producing complex business apps. The promise of simplicity is born in the effortless assembly of that first web page, but the promise dies as you try to implement "real" functionality.

As you start to add more functionality, you become overwhelmed with complexity and new technologies. ActiveX, VBScript, DHTML, JavaScript, Java, CGI, ISAPI, etc. Just in case you don't have your hands full, you also have the added burden of adding graphics and special effects -- it isn't enough to be a programmer, now you need to be an artist as well. As you try to add functionality, you find the implementation curve steepens rapidly. The problem is compounded by the bleeding edge factor of these new technologies.

You might argue that the web can "push" and that you can use rich controls thanks to ActiveX and Java. But if you look at the matter objectively, it becomes apparent that ActiveX and Java are attempts to "kludge" the web. Attempts to get it to do something it wasn't designed to do -- the proverbial square peg in the round hole. The great irony is in the rush to "fix" the web, some of it's best traits are being destroyed. How lightweight is a 15 MB browser? How far off is the 50 MB browser? Instead of the simple, lightweight browser that once inspired us with awe, we have memory hungry, resource eating browsers. ActiveX brings it's own layer of complexity to the application. Juggling ActiveX around the network seems to have its own problems.

Java too has its special features. But the Java Virtual Machine or JVM seems like an odd thing to us. Nobody has ever, ever, ever, asked us if we could please make their machines run slower or their interface seem less responsive. We don't expect that to change.

Furthermore, these are rapidly emerging and therefore changing or "unstable" technologies. Each operating system upgrade -- maybe even each financial quarter -- brings upheaval. Working with the technology is a constant wait; you end up waiting for the features that will finally make the product do what it was reported to do two years ago!

And how about those browser wars? Nothing like mixing a little market turmoil in with your technology just to keep things interesting.

Why ASTA succeeds where the web fails

ASTA was designed from the ground up to be a superior business solution. This isn't an academic solution, it's a practical one.

ASTA was inspired by the web. We took the best features of the web and balanced them against the needs of business users. We also examined the bad things about Java, ActiveX and emerging technology in general. ASTA is the hybrid result of our studies and labor. ASTA takes the best features of the web, adds the capabilities that are critical to businesses, and purposefully avoids the leading bleeding edge pitfalls of other technologies.

ASTA is easy

As depicted in the graph above, ASTA produces complex applications with ease. It was designed to! Global Client/Server is an appropriate use of this technology. ASTA handles datasets as gracefully as the web handles text and graphics. ASTA was also designed to "push" data to clients and to deliver real time messages.

ASTA is a practical technology

ASTA's unique properties are the result of it's unique beginnings. From the start, we decided that this technology needed to appeal to four camps; the system administrators, the application developers, the end users, and the CFO. It took the combined visions of an applications programmer, a systems professional, and seasoned business veterans.

To please the end user, we delivered a native Windows application -- providing a crisp and responsive graphical interface. Because it's a native Windows technology, ASTA programs can take advantage of existing operating system benefits and future benefits as well. If it can be done in Windows, it can be done in ASTA. That includes sharing data with other programs (word processors, spreadsheets, browsers).

For the applications programmer, we labored to present the multi-tiered architecture in an easy and intuitive manner. As a result, a developer with no distributed development experience will have little trouble working with ASTA. In fact, ASTA is surprisingly well-suited to the task of migrating existing "fat client" applications to thin client, distributed Client/Server applications.

The systems professionals received special attention. Too many applications are dropped at their doorstep by programmers that simply don't understand the amount of effort, complexity, and cost consumed by a sophisticated corporate system. They understand the programming world, but make no provisions for the applications overall impact on the system (and therefore it's unseen impact on that part of the business). What good is a $5,000 application that costs $50,000 to install and administer?

Our solution was to deliver a thin client application that can be centrally controlled; it installs from a central server, it is upgraded from a central server, and the business rules are maintained at a central server. ASTA also recognizes that the cost of bandwidth is often the highest recurring cost in the IS budget. We are miserly with bandwidth. And ASTAs ability to operate in several modes provides for unlimited flexibility when trying to preserve or provision existing bandwidth.

ASTA's chief proponent and advocate, however, might be the corporate CFO. ASTA can be connected to disparate data sources; including "legacy systems", AS/400s and mainframes -- custom server interfaces can also be written. Since ASTA has such a small footprint, it will run robustly on inexpensive NetPCs. Instead of implementing resource hungry Exchange type environments, a company should consider stepping off the vicious upgrade cycle and implementing a series of lightweight ASTA applications. The graphical front end extends the life of the legacy systems and preserves the skill investments of in-house personnel. Furthermore, the "rocket science" of writing a complex, globally capable, thin client, Client/Server application is encapsulated in ASTA. Programmers with average skills and experience are able to produce sophisticated applications without needing months of training and studying new technologies.

ASTA is not "trade journal technology"

What is trade journal technology? That's easy, trade journal technology refers to programs or applications that work only in trade journals. When you try to run them in your business on your computers, you discover that the actual solution isn't one tenth of what it was reported to be.

ASTA isn't based on emerging or evolving technologies. It works in real life, not just trade journals. ASTA was purposefully founded on proven technologies like TCP/IP -- an open standard in near universal use. ASTA was intended to be simple and reliable. That is our agenda; to provide and simple a reliable technology to enable the next generation of client/server computing.

ASTA will lower your costs and ease administration

ASTA applications can significantly reduce your TCO (Total Cost of Ownership). The clients can be installed from a central server. Once they are on the client PC they can be self-updating, upgrading themselves as newer versions are placed on the server. There are no DLLs, to juggle, no drivers to upgrade.

At about 1.0 MBs, the applications have such a light footprint that they run well on low-cost NetPCs.

In Summary

ASTA is A Smart Thin Architecture that empowers a new generation of client/server applications. It is a hybrid technology that takes the traditional strengths of Client/Server computing and combines it with the strengths of the WWW. Programs developed with ASTA are LAN, WAN and Internet-ready. They have small footprints -- typically around 1.0 MBs -- and were designed to lower administrative costs (development costs and long term system administration costs). The programs can run on inexpensive PCs, can call the compelete WIN32 API, and have a rich interface. ASTA allows you to design and develop programs that can change as quickly as you do. Instead of fighting implementation details and large scale system adminstration problems, ASTA allows you deliver programs that are relevant to your business, programs that promote your competitiveness.

For a closer look at ASTA in action, please see our Demos.