Some inspiring about the web representation in this article "Patterns in Enterprise Application Architecture" patterns in enterprise application architecture " The author has been developing for many years, is not limited to enterprise-level web applications. Some of the work experience gained in entertainment (such as chat room, instant messaging, web scene chat, etc.) prompted me to explore and think in enterprise applications, and formed this article. At present, there are no obvious articles or works in this area at home and abroad. I hope this article can give a little reference to the Tongren development.
This article is first proposed in the JavaParty party on November 13, 2004, and after finishing.
1 Objective Bringing Standard Follow the HTTP GET / POST web development method often follows such a process: the client sends a request: get or post give the web server, the web server processing is completed, and the result is returned to the client with Response. Before getting the response of the server, the client is waiting, the page is stagnant, and the user will see the browser long wait strip slowly grow.
Google Gmail gave us a completely different experience. You can't feel the jump of the page, and the system is very fast. Getting new emails don't need to manually or automatically refresh your browser. All this gives people feel so friendly, so that it has received many users in a lot of users, and it has become a chased object of Sina, Yahoo and other mail providers.
This is a small example of the web application I have to propose for asynchronous messages (AMOWA), referred to as AMOWA. A web application with Amowa features has three:
1. The system must be a web application. In fact, it is very simple to design and achieve asynchronous calls in a non-Web environment, and it is natural. However, in a web environment, design and implementation are relatively troublesome, and the way thinking will slightly skip. 2. The message feature must be available in the system, both implicit or explicit. In online games, instant messaging tools, etc., the message characteristics are more obvious, and the discussion is also more discusses; however, some enterprise applications can also find some implicit message modes. For example, a business intelligent web client requires a drill, traceable, slice, etc., these operations and return values can be packaged as a message (in fact, there is already relevant specifications, respectively, MDX and XML / A); In the operational web application, the operation can also be abstracted as a message, such as a bug management system, submit bug, view bug, etc., can be packaged as a message. 3. The message must be asynchronous. This is the fundamental difference from the traditional way. The traditional way must have a page switching at a constant operation, and amowa does not have to be. The message is asynchronous transmission. Before the operation is complete, you can see a friendly loading or other friendly tips. After the operation is completed, the UI of the front desk is refreshed in JavaScript / Flash.
2 Amowa's birth process
Amowa has shown more than 10 years from the web page.
The initial stage of traditional chat rooms. The front desk is often necessary to automatically refresh once a few seconds to get a statement of other online users. Later, there was no refresh chat room, more or less hidden frames to handle the timing of the message. During this period, a Pushlet appeared, an intention to "push" to the client instead of the client active "pull". This approach is in the client, just like a page that has not been downloaded will never download; the server side often does not allow buffer and write data to the client through Response.Write and then directly response.flush.
The next time the web application has stayed in the standard request / response method for a long time, until the appearance of XMLHTTP, the application of asynchronous messages is more, and due to the extension of thinking, many applications that use the same thinking have emerged. These applications span many industries, including commercial and entertainment industry, until now, web applications that are asynchronous messages have been able to successfully compete for most web applications, and to improve user experiences as ultimate goals, more and more attention. 3 application scenario
Commercial fields, including but not limited to
l Mail Application. This has been verified on Gmail. Mail application is the most typical asynchronous, message application, in the web environment, asynchronous message mode is completely reason to apply in the mail system client. If there is a way to get new emails without refreshing, let you read / write emails without switching the page, would you still want to go back to the old road?
2 Instant messaging application. Typical no extraordinary MSN Web Messenger. Instant messages do not require real-time. In an instant messaging system, the delay 2 ~ 3 seconds users are fully in line with the user. This precious 2 ~ 3 seconds gives the instant messaging web application provides living space and gives an instant messaging service provider new selling point.
3 Business intelligent client. Commercial smart products are increasingly tended to web - perhaps this is the development trend of the entire world application; the data cubes on the Web are drilled, rotated, and if they need to switch the page, there is not much to accept such systems. This requires frequently operating systems, and Amowa is the choice of hell.
4 Web Map System. Map on www.go2map.com, you can see how nature in asynchronous mode of operation is; the map service provided by ICQ is difficult to accept: After each click or a map, you have to wait for a while. White screen.
5 Other operating systems. For example, a financial information management system, the BUG management system mentioned earlier, has a system that is obviously or abstract as a command characteristic. Note that the domestic government or large-scale foreign projects need for OA and other projects are not suitable for applying amowa. In most cases, the definition of message format is more insignificant than the demand control, the use of the interface, and the usage rate after the project is completed. Meaningless.
Entertainment and game areas, including but not limited to:
l chat room. Nothing is more annoying when chatting while listening to the browser automatically refreshing. More carefully define the Amowa's message structure, you will find more visits to the chat room.
2 web online game. Don't think that it is impossible, please visit www.51js.com, there are many traditional web developers unexpected. Currently: LiveChatv2, a pure JavaScript HTML scene chat room; Chinese chess, pure JavaScript HTML online Chinese chess. At present, Taiwan has a real web network instant strategic game, is running online, a monthly card is dozens of tens of tens. Of course, due to the limitations of asynchronous messages, web online games cannot be real-time, so the current web online game is limited to a field, such as chess, community, and simple online games. 3.
4 Advantages 4.1 From the user to see:
1. Better user experience. Many senior users are reluctant to hear the sound of the browser refresh. This user group is expanded. In modern enterprise web applications, there is often a timely message delivery; let them hear the sound of refresh is not suitable. Amowa's introduction will completely brushless, and users feel better.
2. Better user experience is more friendly for users. Most users feel the long time in the face when switching the page, and feel unnatural. In operation in business intelligence / report, single page operation is particularly important. 3. Better user experience is more friendly. Before operating the data returns, the user will see is not a white screen and long browser status, which is more friendly tips and status. For senior users, such changes will surprise them.
4 .... Hey, better user experience Due to pure data transmitted in the system, the system seems faster than ordinary applications, which is of course better.
4.2 Technical Views
1. In some scenarios, the client can be a pure HTML, not a hateful JSP TAG, or TapeStry is difficult to understand JWCID (actually not understand ^ _ ^), or Struts That terror, or There is no IDE tool supported JSF. Business logic, server-side specific language feature is completely separated from the client. The art can truly hesitate to do the page.
2. The server side can make some interesting designs, such as task queues. Since the client is sent is a message, the server side can process the sending message in accordance with the queue, without having to respond immediately. 3. It is easy to achieve distributed deployment. Due to the complete separation of the client and the server, the server-side distribution, state migration, cache sharing will not be a problem.
5 AMOWA-based design Based on AMOWA design will be divided into two parts: a typical web application for enterprise-class typical web applications and entertainment games.
5.1 For enterprise-class typical web applications
Basic principle: A typical enterprise web application must be a hierarchical structure, a well-designed application. The hierarchical design means that the data layer, the business logic layer and the representation layer can be clearly separated.
Amowa is designed in a web representation, which is connected to the system's business logic and front-end web page. Amowa Gateway is responsible for analyzing the message packet sent by the front desk, resolving the message package into the corresponding business operation, calling the business logic operation, serializing the results, the package is a message, sent to the client.
The client has a client engine that can receive, parse the message package, and refreshes the UI according to the message content. The refresh here may correspond to a JavaScript script, or may correspond to a Flash's Action Script script.
Amowa is positioned at the same level of Struts, WebWork, Tapestry and other web frames and can replace them. The figure below shows this architecture: this web application is in Amowa, with the largest feature: less interaction between sessions. In Amowa designs on the following entertainment games, the interaction between sessions is very important.
5.2 Amowa design for entertainment games
Entertainment-oriented Amowa's fundamental difference between enterprise web applications is higher than that in front of the session, such as in a online game, often need to know the current state of another online player, so there is a central context in this design To save this information to ensure the interaction between online operators. The basic design is as follows:
Context is connected to basic underlying facilities, for example, saving players experience, buckle points, etc.
6 Implementing the following is a pseudo code for an AMOWA interface * Client packages into messages and sends: clientoperation.sendMessageBundle (msgbundle, callback); Callback defines the processing policy of the message. * AMOWA Gateway is responsible for obtaining the transmitted message reception and processing messageBundle = buildMessage (request); // Request the packaged MessageBundle returnedMSGBundle = process (messageBundle); // process the message packet sendReturnedBundle (returnedMSGBundle); // send the processing result * Process method inside, simple to call the business logic layer: bizdto = bizService.DOSMETHING (); Return Bizdto; Amowa Engine will generate BizDTo sequence to the system recognized message format, generate a message package. The above implementation is relatively simple, in fact, it is not too difficult to design such Amowa Framework technology. If you want to be lazy, the implementation of XML-RPC can be used directly. XML-RPC is implemented in almost all languages.
7 Related Technical Client Technology: DHTML, JavaScript I have biased these two points in the text because I am more familiar with these two technologies. In fact, Flash is more suitable for the front desk performance. Of course, what technology used for front desk does not affect the architecture of Amowa. Amowa defines a communication method between the client's server, not the client implementation.
Server-side technology: Any server-side technology is available. However, server-side technology-oriented features can be more free and reasonable in implementation. Those old-fashioned server-side technologies such as ASPs, want to implement an Amowa framework more difficult, this is very prominent when designing Web online games.
XML-Binding technology must be required, whether it is a client or a server side. This is because our message is often defined by XML. When the server is returned to the object, it is possible to directly serialize the XML will provide the package to make the package convenience; if the client can bind the HTML or Flash a control directly with the XML a node or attribute, then the front desk Workload will be less. Given that the server-side XML binding has many different implementations, such as JAXB, CASTOR, JIBX, etc., the author recently binds the XML object to the HTML element in tried no browser differences.
Selecting a messaging protocol is necessary. There are currently two options: Web-Service and XML-RPC. The message characteristics of the existing system are clear and unlikely to expose each method to the outside world, Web-Service is the least recommended. Web-service redundancy information is too much, transmission or resolution will bring time and bandwidth loss. If there is no time to define a message format, then XML-RPC will be a better choice. He has better packaging for data types, enough for web applications, and has enough language implementation support, clients and server are available.
If time is sufficient, it is best to define the message structure itself, and the encoding, decoding method. This is not a very complicated thing. This encoded message can be transmitted at a minimum bandwidth loss. This is especially important in the application of bandwidth, such as bank business systems.
8 Related question and answer Q: What is the relationship between amowa and RIA? A: There is no relationship. Amowa defines a new type of interaction in the web application - uses a message. RIA can be an implementation of the Amowa client, and Amowa's client implementation can be Flash, XUL, or HTML.
Q: The relationship between amowa and XMLHTTP? A: XMLHTTP is a means of Amowa implementation without refresh, asynchronous messages. There is currently only such a means to get asynchronous connections. Other ways, such as dynamically loading remote JavaScript, dynamically load remote web pages, how much synchronization, can cause the client browser to be unavailable. Q: Is amowa implementation? A: No. I am writing one, mainly for online games. But due to the busy work, slow progress. Basic thinking like the above description, interested colleagues can achieve themselves, benefit mankind.
Q: Send and receive why is MessageBundle instead of a single message? A: This is to ensure the efficiency of execution. In LiveChatv2, users will send a message each time the mouse click, if the user's mouse click speed, such as dozens of times per second, such dense access may cause the server unnecessary busy. Therefore, the client takes no time to record once, bundle the mouse action of this time into a message package, sent to the server.
Other questions, welcome: mechiland [###] gmail.com
9 Summary AMOWA introduces a new web development mode, you can replace the standard MVC development method! Amowa's introduction, fundamentally, is completely better to give users a better experience, so that the product is more human and competitive. Faster.
Excerpt from: http:/Webuc.Net/Mechiland/archive/2004/11/15/2195.aspx
