Ajax| Strategy | Technology platform
a Web application framework based on AJAX architecture
Before I mentioned the "Ajax-like" architecture, the AJAX framework I'm talking about now is the framework that is provided specifically for this AJAX architecture. At present, I have not heard of particularly good in this area of the popular framework. But I know my side,. NET domain, Java EE domain or PHP platform has such a framework and applications, I think, it is because there are many such applications, so Ajax will be like a pattern, is written with a special noun. However, I feel that Ajax has become synonymous with Ajax feature, become synonymous with XMLHTTP, become asynchronous communication, do not refresh the technical representation of the page. Until I read the Ajax in action book, I was linking Ajax and the architecture of the system, the design patterns, the serialization of distributed objects and my previous projects and experiences.
I've modified some of Jesse's graphs to illustrate what I think is an AJAX based architecture.
This is what I said above the "Ajax-like" architecture, first it is a Web application, its performance layer with DHTML+CSS + HTC Control + Javascript, server-side. NET or any server-side technology, the middle is serialized and deserialized in XML to pass data.
Simply put, the client needs to encapsulate the requested data into an XML data passed to the server side via HTTP, the server handles the request, and the results are returned as XML to the client, which then processes the requests and then uses HTML+CSS to display them. In fact, if it is not a Web client (browser) problem, this is the simplest architecture, but the key problem is that we say that the JavaScript-side of the object encapsulated into an XML, and to the server-side parsing the XML into the Serverõs object, and then encapsulate the results into XML, back to the client ( JavaScript), the client also parses the XML data and then becomes the problem of serialization and deserialization of objects in JavaScript. Another problem is the presentation layer of the problem, how to show, with what control?
Therefore, an AJAX-architected Web application must address the following issues:
1. Bidirectional two-way serialization problem
2. The problem of presentation layer
3. Data security on the client and server side during transmission
4. Performance problems
5. Internationalization support
The most fun two-way two-way serialization problem, the first contact is JSON, its problem is extensibility, data type support and performance, but the platform is relatively good, any browser can, because it does not need to use MSXML2. Domdocumen parsing XML is essentially a string description object, followed by a multiplatform application migration experience (such as CORBAR,J2EE background application), began to touch XML-RPC, Ice,hessian,web services and so on. XML-RPC has JavaScript support library, Web services also have JavaScript support library, that is, you can use JavaScript to access or access to Xml-rpc/web services objects, But if you use it as a major communication protocol, there are other problems, such as performance, internationalization, and it bothers you, and one of the major problems with XML-RPC and Web services is performance, because they're transferring too large a size, But obviously using these to achieve an AJAX feature, that's completely fine.
For example, is Atlas not currently using a JavaScript library to invoke Web services? , so you can do the same, and you can also use xml-rpc.net to quickly implement a service, and then use the Scotandrew XML-RPC JavaScript library to send an XML-RPC in JavaScript The message requests this service, and then asynchronously obtains the result and then unfolds it. So from the implementation of the technology, AJAX features are very easy to implement, but from the architectural point of view. You need to think about more factors. Of course, until finally, we found that the perfect solution in the project was for you to write a bidirectional two-way serialization engine for your JavaScript clients to use.
This is the second question, the interface performance problem, the problem is also a big problem. This problem always exists forever, Ajax no one will pay attention to these before, but today is different, I think there will be a big leap in the future, Yahoo! not recently also open source his Yahoo! Web UI Library, Atlas also indicates that you want to provide more front-end UI controls. In any case, the question is whether your team or organization has a library of front-end JavaScript that has been tested by the project or customer. Whether you write it yourself in JavaScript or write your own set of HTC Control Library, in short these are very important in the AJAX architecture.
Another thinking problem with Atlas is that server-side controls can be integrated in some way with JavaScript controls, and we used HTC to solve reuse, performance, behaviors, and even template functionality. But new features such as data binding, caching and validation, and even data encoding and compression, encryption and decryption, the Javascript UI front-end still has a lot to do, and how to seamlessly integrate both, which has great significance.
Then security, performance, internationalization, and so on, the architecture of the problems need you to consider and solve, if you look at Ajax, I think, the current AJAX framework has a long way to go, the same truly perfect support AJAX architecture still need to continue efforts. These are also my views in this column.
Putting these together, the development package or framework for an AJAX architecture should be a platform for a solution that contains several of these issues (two-way serialization, Javascript UI Performance Library, security, internationalization, and performance, and so on).
Also, you might say, isn't Ajax? Why do I have to be so complicated that I have to get to the architecture level.
I think
First, look at the architecture of Ajax, and then apply the relevant technology, than you directly use an AJAX framework and then understand Ajax, you will gain more from the process.
Second, for a development team/organization, the real AJAX architecture of the product can bring benefits and specific productivity. For example, I have such an advantage around the team, they have a unified set by the JAVASCRIPT+HTML+CSS+HTC front-end performance layer, and the background of the business system has two platforms, one. NET platform and Java EE platform; I also have such a team around me, they have a unified set by javascript+dhtml+css+htc+vml+asp. NET's front-end performance layer, but their background business layer comes from. NET platform, Java EE Platform and UNIX platform, I can't say the application of Ajax architecture seems to be the unified Web presentation layer. Because from today to see their tomorrow, may be, a asp.net v2+atlas unified performance layer, a unified Cab+smart Client Unified performance layer, can also be a WPF 3D Unified performance layer, can also be a XGL Desktop unified layer ...
Third, from this architectural level, you can also easily understand SOA or ESB concepts, and the difference between Ajax architectures, compared to SOA, is that Ajax has enough loose coupling, but it is still centered on the data being applied, more on the messages architecture, and on the popular ws-* The support of the agreement is very limited.
But if, today, you or your team already have an AJAX architecture application, you should be careful to choose the existing AJAX framework, because the characteristics of these Ajax, as opposed to the current architecture, is small, but can be a great harm to a factor. There may not be many or many of these, but only if we think from a higher and deeper level, we can make the right choices and benefit from new Ajax technology and research.
Conclusions
When we go back to the beginning of the article, I want to illustrate my view that the ajax-net framework or implementation is divided into two categories, one based on AJAX application architecture and one based on Ajax features, and most of the ajax-net frameworks or implementations are currently based on Ajax features, A code or framework that is provided in a add-in manner.
Ajax-net Implementation/Framework selection recommendations:
Asp. NET control form has become the primary form and choice for connecting server and client Ajax communications.
The way the client invokes the server-side page is an important means of Ajax, making it more flexible for clients to obtain server-side data.
Magicajax.net,anthem.net used the "Hook asp.net" and add-in technical means, the use of more affected by the two frameworks, the simplest application, The first choice is magicajax.net, but always give priority to using Anthem.net.
If you write your own server-side controls, you should first master the technology of Anthem.net and then make your own controls Ajax-specific.
Magicajax.net, Anthem.net and Wwhoverpanel support for internationalization have yet to be strengthened.
Before the official release of Atlas, In ASP.net's application, it is preferable to use a similar wwhoverpanel technique in your own project, that is, to use the client callback function as much as possible, to use its method invocation function where it is particularly needed, to give full play to the AJAX features, rather than to deliberately choose an AJAX framework for Ajax.
The strengths of Atlas are the integration of server-side and client control features, client data binding, checksums, built-in multiple client Ajax feature UI or components, integration with ASP.net profile, membership, role services, and web Integration of service and WCF services, as well as the support of good internationalization/development tools. Because it is a complete solution, the biggest weakness is that it cannot be easily used by the old AJAX architecture applications. In addition, the product is still under development, distance deployment to the production environment requirements still have gaps.
Lightweight bidirectional serialization takes into account JSON format, security issues can add fields to the passed object, and then verify on the server side.
For organizations that already have a serialization framework in place, the main goal is to migrate/upgrade the framework to ASP.net V2 as soon as possible, rather than prioritizing the implementation of an AJAX feature.
Ajax requires sufficient power to focus on front-end UI presentation or development, so the choice of AJAX implementation/framework is first to examine the implementation of its client and the Web UI provided.
After reading this article, I hope that in the future when we talk about Ajax, as a technician, I don't have to talk about Web 2.0, I can clearly express the concept of Ajax
If you're an architect, Ajax is no longer an asynchronous XMLHTTP call, it's no longer a refreshing page, it can help you review your application's architecture.
For your team or boss, Ajax can be a strategy for your unified interface presentation layer, and it may also give you the opportunity to create a set of UI libraries that can be reused at a departmental or corporate level.
Also for JavaScript developers, Ajax allows you to understand some of the business and prove that the foreground web developer is just as expensive and that background development can be low-tech.
For enthusiasts of SOA, AJAX architectures allow you to stand on the message-oriented architecture and systems to look at service-oriented; Generally speaking, you need to have a message-oriented architecture internally, then you can easily extend it to a service-oriented, internet-oriented distributed architecture.
Finally, do not discuss the demise of Ajax, because Ajax for programmers, is a balance of power strategy, in Ajax, the Web front-end developers have been renewed attention to become an important force.
PostScript
It was a bit painful for me to write a few paragraphs of these words, because I didn't think so much. So you don't care too much about my evaluation and description of the various frameworks, these are the technical aspects of the thing, in fact I write this text, mainly to highlight the Ajax architecture concept, as well as design patterns and Web application Architecture refactoring considerations, continued and you can use a cross-sectional perspective, Ajax to see your current application and architecture To gain a deeper understanding of the serialization of distributed objects, performance, security, and the integration of Ajax and ASP.net server-side controls. Finally welcome everyone to treatise.
- Ajax: A new way to build Web apps
- Discussion on the error handling mechanism of AJAX (2)
- Discussion on the error handling mechanism of AJAX (1)
- First experience. NET Ajax Brushless New technology
- A brief analysis of Ajax development Technology in Rails system (4)
