Author: O. Shalnev
Rendered: D. Katsera
Reflecting on the situation in developing client-server systems that were forced to tasks, which require a different approach to that, which is now available on the market.
A history of network applications is well-known. From the early evolution of terminal stations led to a file-server solution, and then, with the advent of database servers, to the classic client-server systems, consisting of 2 parts, Server databases and "client". Such a scheme and now enjoys a well-deserved popularity and the nature of the popularity of technological simplicity of implementation architecture client-server. Access to database opened developer opportunities to manipulate the data masking mechanism for the exchange of information between the client and the server. The objective was the implementation of the programmer-friendly user interface and development of effective SQL queries. But on the other side of the weights are drawbacks 2 bridge model. First and foremost is the need to create a client program to be fully realized demo logic, and, sometimes, and the logic of the task itself. The full value of the client could be significant in case of heavy systems. This scheme became known as bunch of "thick client" to the database server.
Of course, if changes in the logic of the system or the interface of a need to update the client software on all workplaces users. This fact complicates the process of tracking systems, forcing developers to apply automatically maintain client program to date, the swap of modified modules. Supporters of 2-point approach from the world of Java, taking advantage of its platform to easily update the client program is putting himself in a credit score and typing in the discussions. Despite the advanced methods of software updates, is the need to update the client application remains.
The second problem is that the model is to publish a database server on the network. If a local decision, such an approach is let and acquitted in the case if the "problem" arises and begins to live in the boundless spaces of Internet-but publishing server bases in large networks has become a serious headache for system administrators. Embedded protection, authentication, encryption channels do not provide 100% secure.
Finally, the third complexity of 2-point architecture - is a possible demand of bandwidth channels. In a large, growing system is not always possible to monitor the effectiveness and wisdom of SQL queries. Often, requests and, more importantly, taken by motorcade server data is very large and can significantly reduce the speed of data exchange between server and client, to increase response time to requests that immediately affect the comfort of the user. This fact was well understood and helped the evolution towards of 3-chain architectures.
Under the phrase "three-tier" the people understand different. Many refer to three-tier architecture and terminal solutions. But whether such an understanding of things is justified? Can one attribute to the three-tier architecture terminal solution?
IT professionals have to use terminal solutions for the adaptation of two-tier systems in three-tier of contact with the "thin client". Terminal means are quite a lot. That decision, the use of X11 Protocol, Windows Terminal Service, Citrix, No Machine. But can these tools be used to be acceptable in the industrial exploitation? If you look, it shows that the very architecture of tasks, working in the terminal environment, usually written as a 2-makers and through the terminal means we actually camouflage bottlenecks two-tier model. Such decision is very demanding, both in terms of memory, and network resource. Indeed, starting application on the server side, you use memory not productively every time dragging a cargo of graphics and presentation logic. There is a certain need of a very solid server machine to ensure the normal operation of at least 30 client sessions. However, this depends on the resource problem. Reduced speed of the connection (client to the server) immediately affects the comfort of the user. Either the deteriorating quality of the image or raise boring delays is occurred. Advocates of terminal solutions are always talking about the relative modesty in consumption of telecommunications terminal client, neglecting to say about the server connection. Throughput of server connectivity – is a limited resource. It is not difficult to calculate how many simultaneous connections can accommodate a terminal server connected to the world at speeds of 2Mbit. Of course, terminal solutions are good, can and will occur as a tool for system administrator or privileged user, but if the server does not have to serve 30-40 and 300-400-5000 active compounds that can hardly be considered terminal scheme as a valid, reasonable, and the main thing possible.. And in vain adherents of "terminal schools" to think that small and medium businesses do not have tasks that do not fit a terminal service. For example in the information system of medium and small store can operate more than 40 jobs. Trading companies offer its partners access to information resources. Even small trading platforms may have a significant number of clients (traders). Thus it is understandable that for any large-scale solutions terminal means is not suitable. However, the terminal approach, paired with traditional two-tier model of development, remains the most popular and in demand. What is the reason for such popularity? Why are so expensive and resource demanding solutions to problems so attract developers. The reason for all is in the same ease of implementations. The programmers still do not have to think about "clients" and "servers", he only write a program using the library user interface and database access. Simplicity - the key to popularity. It is that simplicity luck in different approaches, as it will be described further.
Developers who want no surrogate, but the real three-tier model to understand the need to implement a balanced, devoid of graphics server load, and this "thin client" program that would only deal with interface. Developers were divided into several groups and each went their own ways. One group of armed conventional HTML browser and has used it as a "thin client". Parsimony of all available means to build the user interface is no confusion. However, very soon, hypertext mark-up language magazine pages became accrete additional "extras." However, no DHTML, nor layers and Java scripts has not radically changed the situation, but made it only more confusing. Browser war has made its share of problems adding for developers, forcing them to seek support of the maximum number of browsers. It is not added quality to the code but considerably increased the size of pages. But not even the size of pages and unfriendly interfaces become raise questions. The style and approach to the development of such systems differed from the comfort of the programmers of old classic two-tier systems. The need to think in terms of "pages" and "context client" had broken former server applications. The developer must generate by hands, either from a template the desired at the moment interface page. Enrich its content, while not forgetting to put it inside the control numbers. These targets will help the server remember what is at stake if the client suddenly wants to press button "A" in interface "B". And, of course, it must take the line from the client browser to deal with, and thereby control, status point is, in its memory of the image of the client session, to take certain actions and create a new page. It is rather difficult.
Of course, programmers have sought to simplify the development process making it similar to the classic. A variety of solutions began to appear. Many PHP libraries began to appear in different languages. Java world is particularly rich in such resources. But all this masking of architecture is the desire to make server software more straightforward and logical. In trying to make user interface more convenient, reasonable and modern began to appear special "thin clients" who worked with specially created for them page description language. Some languages integrated into browsers (XUL), but the principles of server software that does not change. Developers still lacks simplicity.
Another group of armed systems object brokering. RPC, CORBA, COM, DCOM, RMI, SOAP - the tools that allow developers to change attitudes to create applications. It is a tempting prospect to remotely create objects that cause the methods and procedures. True if a "client" will address himself to the server for remote procedures; it becomes a "thick" (rich client) client. If the "client" asks the server data for the current generation of interfaces, it is simply intellectual and complex browser. "Thin client" based on CORBA technology contains the entire set of interface tools, allowing "server" how to manage their resources. Some kind of remote, located on the client side repository of graphic tools. Wonderful idea, but it is difficult to implement. Programming Interface CORBA systems is not easy and not laconic. Certainly in the Java world, these issues are somewhat easier, but not all write in Java. And then, what is the creation of the interface? This is a long sequence of calling-type: create new window, paste button, type in button. Working with CORBA methods such sequences appear to be a big flow of small-sized packages to be prepared, shipped CORBA services and accepted by the other party. The sequence of small packages or variable causes slowing the processing of data in the TCP / IP stack. There is a view that the use of remote procedure call in case of need of extensive computation and not so often. This view is difficult to disagree with.By analyzing the above approaches to address the development of client-server, author of the draft Vedga set out to create a tool to meet the following requirements:
- The programmer must create applications like ordinary non-graphics program.
- Programmer should not be difficult to encumber additional programming interfaces.
- The programmer should not be loaded with additional knowledge about how to organize interaction between the client and the server.
- The programmer should not think about the client side.
- The programmer should not think of the network side of a decision.
- Undemanding to telecommunications resources
- Interaction between the client and server must be at minimum speeds.
- "Thin client" as a means of customer interaction with the server.
- The client portion of the tandem should be minimal in size and undemanding to resources.
- The client portion should be cross platform and work for major commercial operating platforms.
- User "thin client" interacting with the server should not see the difference between normal local application and a network.
As a result of reflection and attempts to create the most convenient tool for the development of network applications, has been the emergence of the draft "Vedga ". Vedga Instrument is a tandem library design for servers and" thin client ". Library provides developers to not think about all the complexities of creating network applications, but concentrate on creating the program. Programmer supplies with advanced set of tools that are familiar to the developer of the user interface. An opportunity to freely operate such concepts as "window", "frame", "menu", "button" and other well-known arsenal of tools for graphics libraries. Cross platform achieved by the well-known library Qt, Developer Company is called TrollTech. Naming classes, the parameters of functions and internal structures library Vedga is maximum identical to naming in Qt. Supported mechanism signals and slots that became the hallmark of Qt. In that developers Vedga see additional benefits to a large reservoir of programmers using Qt in their practice, easily adapted in classrooms Vedga. Moreover, it is possible to transform the existing Qt applications in the network. Easy and fast way to design allows fully move the load on the server side, providing "client-only interface functions. The interface wrapper library Vedga is hiding mechanism of transport management information and data between the client and the server. Optimization key algorithms have been assembling requests and answer packets in the packages and transfer data prepared in summary form. Achieved client-side comfort from the use of the network Vedga program is identical to the maximum comfort of working with the usual local program. You are the interface to which it is used in all its functional diversity and is not known discomfort of working with interfaces based on HTML browsers. The work of a programmer using the library Vedga becomes a server program (Daemon), is fully ready for operation.
In this example, you can see how close the methodology of establishing a network Vedga-annex to the methodology for creating applications in Qt..
GGroupBox * Window:: createSecondExclusiveGroup ()
GGroupBox *groupBox = new GGroupBox(tr("E&xclusive Radio Buttons"), this);
GRadioButton *radio1 = new GRadioButton(tr("Rad&io button 1"), this);
GRadioButton *radio2 = new GRadioButton(tr("Radi&o button 2"), this);
GRadioButton *radio3 = new GRadioButton(tr("Radio &button 3"), this);
GCheckBox *checkBox = new GCheckBox(tr("Ind&ependent checkbox"), this);
GVBoxLayout *vbox = new GVBoxLayout;
As you can see the differences are insignificant. The result of the program, a fragment of which was presented earlier, on the client side looks the same as for X11 platforms, and for Ms Windows. These capabilities enable developers to base position Glan as a tool for creating Internet applications with advanced user interface. A simple programming server (identical to the principles of conventional programming graphical applications) gives developers more options for creating a modern network applications and approaches to the creation of a unified corporate information environment.