InternetGTS uses thin-client technology to enable a secure and efficient connection over the Internet. This approach allows superior access control and logs and auto -updating of software, thus minimizing administrative overhead. Many people are confused by the term "thin-client"... Thin-client Q & AFirst, what is "thin client"? I know that Citrix is thin-client application.
So why not just access the application remotely?
So is it a Web application?
So you do not use Java, how does your program work?
So you can run from a web page?
What about XML, SOAP and .NET?
GTS Development MissionThe objective is to deliver the application to the end user based on the following criteria:
More on HTML – “Web-based” applicationsThe term “web-based application” is not a correct term. In strict terms, the “Web” is an infrastructure for exchanging data in HTML format. HTML is not an application programming language or environment. It was designed to reliably exchange data in unstructured format. Originally, HTML only displayed information from a web server. Later, HTML allowed users to input values in a page and submit those values back to the web server at a page-level batch mode. An application can be written (in any language) to receive and process those values and, if necessary, generate another HTML page to post back the results. There are several weaknesses to this old-fashioned batch approach to processing (if you are over 40 then you may remember the computer cards you filled out in junior high for standardized tests and to register for classes) No application intelligence at the user end. Validation of input can only be done in batch mode, meaning that I can input incorrect data and the system cannot tell me I made a mistake until: – I have submitted my input – The server application has received it – The server application validates it – The server application generates a HTML-based response – My browser receives and displays the HTML-based response. Data input validation is a fundamental element of an application. HTML-based “applications” do not support these features. Addressing the weakness of HTML – the role of JavaThis weakness was recognized long ago and addressed by the development of client-side application functionality in which the user downloads a thin-client (presented to the User as either an applet or a plug-in). This applet then allows some intelligent processing, often within the context of the HTML page. There are two approaches to developing client-side applications: 1) User standard industry-supported development tools such as Java. 2) Use your current development tool and create a n-tier architecture. Other alternatives are to avoid developing client-side applications are possible by using: - emulation software - direct remote connection In addition to other drawbacks, these two non-Internet alternatives are not attractive from a sales and marketing point-of-view. Java is a programming language that allows a web developer to add some intelligence into the web page. The Java application is usually bundled in the web page. In fact, Java is actually a type of thin-client application since it runs locally. Microsoft calls it a Virtual Machine (VM).
If you go to Sun Microsystems’ web site and to their pre-release of Java for XP, you will see the page below explaining that you will be downloading and installing a program (called plug-ins) that will run locally.
Next you see a dialog screen about installing the Plug In (see below).
Other examples of thin-clients that are registered as plug-ins on my browser are ICQ from AOL/Time Warner, Real Player from Real Networks and MSN Messenger from Microsoft. In fact, the thin clients can be called up from within the browser environment in the tool bar (see below).
However, in each of these cases, it is possible to run the programs without a browser active. They all use imbedded Internet technology to handle communications and bypass HTML. Our TechnologyGTS uses an advanced tool from Asta Technology Group. As noted on their web site, ASTA is being used by hundreds of developers all over the world. Small development shops as well as large, global corporations and government entities including the AT&T, HP, MCI, Seagate, the US Army and the Canadian government are using it. Technical information about ASTA and their take on thin-client can be found at: http://www.astatech.com/support/white/ The following is an excerpt from a document by ASTA Technology The World Wide Web (web or WWW) is a fantastic piece of technology, it's a revolutionary tool. But like all tools, it 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 lightweight browser, an appropriate protocol like HTTP, and a powerful 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. Even though 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 -- with or without JAVA and 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:
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 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 bleeding edge pitfalls of other technologies. 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 complete 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 administration problems, ASTA allows you deliver programs that are relevant to your business, programs that promote your competitiveness. |
|
||
