A New AJAX Approach - Client-side Controls Invoking Web Services

Posted Fri Jan 25, 2008 @ 9:29 AM

Since the time we shipped our first production suite of native ASP.NET AJAX controls back in November of 2006, we've been experimenting with new ways of doing efficient incremental page updates. We felt that we had something promising on our hands with full fledged client-side controls. The ability to create high-level UI elements (menus, treeviews, grids, etc.) on the client seemed like a solid foundation to build on.
 
Our research produced a new high-performance AJAX technique which is currently gaining quite a bit of momentum among our customers. I will explain how this technique differs from standard AJAX techniques, with comments on ease of use, performance, elegance and the available client-side features within each technique.  

I highly recommend trying the live examples associated to individual AJAX techniques below. Significant performance improvements are quite visible when the same functionality is implemented using different AJAX approaches. The final example is so fast that it truly feels like a local desktop application.
 
Overview of Common AJAX Techniques
 
Technique 1 - Server-centric AJAX Containers (ASP.NET AJAX UpdatePanel)
 

The server-centric AJAX container technique is employed by the ASP.NET AJAX UpdatePanel control as well as several AJAX solutions sold by the leading 3rd party control vendors. UpdatePanels are driven entirely by ASP.NET postbacks. AJAX applications are created by wrapping postback-based ASP.NET portions of the page and specifying which triggers (server-side events) will cause certain page areas to re-render.

 

Ease of use: The most obvious advantage of this approach is that it is extremely easy to implement. It is really not much harder than building a vanilla postback-based ASP.NET application and then wrapping certain areas of the page with UpdatePanels. This approach is ideal for quickly adding AJAX features to existing ASP.NET applications.

Performance: The biggest downside of this approach is performance. UpdatePanels always post the entire page - including full viewstate - to the server. Even though the required AJAX update to the page is often minimal, its server-side page processing essentially takes the same resources as when doing a full postback. The response sends raw HTML back to the browser, adding kilobytes to the required network traffic to process the AJAX request.

Elegance: The server-centric AJAX container technique is fairly elegant from the implementation point of view. Page areas are cleanly wrapped by UpdatePanel instances and AJAX updates are accomplished by mapping server-side events to triggers. All AJAX magic is performed by the UpdatePanel control itself.

Features: All features exposed to the developer using the UpdatePanel control are entirely on the server side. The control was not designed to be driven by client-side logic. The server-centric approach lacks the finer level of control on the client, which is definitely needed to build sophisticated AJAX apps with hyper-responsive user interfaces.



Technique 2 - Client-centric AJAX Containers (ComponentArt CallBack)

ComponentArt CallBack is similar to the UpdatePanel control in its high-level concept of acting as a generic AJAX container for ASP.NET content. Both controls allow rendering custom ASP.NET content (including server controls, user controls as well as literal content) through AJAX callbacks - without reloading the entire page.

However, ComponentArt CallBack is driven entirely by its client-side API. Developers specify exactly when a callback will be triggered and exactly which parameters will be sent to the server (CallBack doesn't post the page by default). This triggers a server-side event, where the developer has full control over what will be rendered back to the client.

 

Ease of use: ComponentArt CallBack is not as easy to use as the UpdatePanel control. It requires JavaScript code to initiate the callback request through the control's client-side API as well as implementing a server-side event handler to render content back to the browser. In most cases this amounts to just a few lines of code on the client and the same amount on the server.

Performance: Requests made through the CallBack control are extremely lightweight in terms of network traffic. However, each request has to go through the full page life cycle and the response typically generates HTML and sends it back to the browser.

Elegance: The CallBack control hooks into the page life cycle and exposes the native ASP.NET object for rendering (HtmlTextWriter) to the developer. While the developer needs to write custom code both on the server and the client to perform an AJAX request, the level of control that is gained makes it worthwhile in most cases. 

Features: The client-centric AJAX approach exposes more capabilities to rich web applications with highly-responsive user interfaces because all AJAX request decision-making logic resides within the client-side event-driven code.



Technique 3 - Manual JavaScript Coding Against Server-side Logic (Ajax.NET, ASP.NET 3.5 Script Services)

The previous two techniques revolve around the ASP.NET page model and are essentially delivered as ASP.NET server controls. In contrast with these techniques is a pure JavaScript approach originally introduced by Michael Schwarz with his Ajax.NET library. The core idea is to provide a way to mark methods of any server-side class with the "[AjaxMethod]" attribute and then be able to invoke that method from client-side code.

A similar technique is available with ASP.NET AJAX/3.5, which makes it incredibly easy to expose a web service and invoke it directly from client-side code. Significant performance improvements of this approach over the previous two are probably the main reason for its incredible popularity within the development community.

 

Ease of use: Invoking server-side logic on the client is easy with Ajax.NET / ASP.NET 3.5. However, this solution assumes quite a bit of manual JavaScript coding in order to generate and update user interface elements of the page. This is why it doesn't get high marks in the "ease of use" category.

Performance: There are two important performance breakthroughs of this approach: 1) Since methods of any class can be invoked through client-side code, the server-side request processing doesn't need to go through the ASP.NET page life cycle. The client-side request hits exactly the method it needs and it receives exactly the response it needs. There is no waste of server resources. 2) The response doesn't contain HTML markup. Rather, it contains only the data requested by the client. This can reduce the network traffic required to process the AJAX request by an order of magnitude. The received data is used on the client side to generate or update user interface elements.

Elegance: All functionality included with Ajax.NET or ASP.NET 3.5 Script Services is well architected. However, the overall solution is missing a piece of the AJAX puzzle and this is the reason why this approach loses points in the "elegance" category. The fact that developers are stuck with generating the user interface layer leaves the application with quite a bit of JavaScript code to maintain.

Features: The Ajax.NET library as well as ASP.NET 3.5 Script Services are loaded with client-side features. They contain the ability to easily invoke server-side logic as well as serialize .NET objects to their JSON representations. They don't, however, have the ability to manipulate high level UI elements (menus, treeviews, grids, etc.).

AJAX 2.0 - Client-side Controls Invoking Web Services

The new AJAX approach builds on best performance practises presented in the previous technique: efficiently executing server-side logic by invoking ASP.NET 3.5 web services and only sending data over the network. However, instead of requiring manual JavaScript coding to create and manipulate user interface elements, this functionality is now built into ComponentArt Web.UI client controls.

 

Ease of use: High-level client controls expose API methods to invoke web services. The structure and content of those controls is automatically populated with the results returned by the web service and the update is immediately visible on the screen. Even though some client-side coding is required to create and maintain user interface elements, it is reduced from many hundreds of lines to just a handful of high-level API calls. Not as easy as using the UpdatePanel control, but pretty close.

Performance: As already stated, this approach builds on best performance practises presented in the previous technique. However, the overall performance of an application built with this new approach actually exceeds the previous one. Additional performance improvements come from extensive client-side UI generation optimizations that we've built into the ComponentArt Web.UI suite.

Elegance: A high-level description of this technique is simple and powerful: "Objects on the client (client-side controls) communicate directly with objects on the server (web services)". The server-side logic of the application is delivered as a collection of web services - without any preconceived user interface decisions. This produces a real separation of tiers and greater code reuse options. Those web services could potentially be reused by multiple types of applications: mobile, smart client, Silverlight or other ASP.NET apps.

Features: Not only is AJAX request decision-making logic in the same domain as the rest of the app, but it is transparent to it. Updating a portion of the user interface through a fast AJAX request is no different than invoking any other client-side API method.



Summary

The new AJAX technique presented here is an evolution of the previously available techniques, rather than a radical departure from them. It builds on the strengths of AJAX best practises, while introducing something new: full fledged client-side controls capable of communicating directly with web services.

It's important to note that there is no clear winner for all application scenarios. All of these techniques deserve consideration, depending on the specific situation. For example, ASP.NET AJAX UpdatePanels might end up being chosen for apps that run on fast internal networks. Client-controls invoking web services are a great option for high-performance apps with rich and responsive user interfaces. Mixing various techniques within the same application is also a perfectly viable strategy.

Comments

Posted on Fri Jan 25, 2008 @ 9:29 AM

All of your links are referencing v3.corp.componentart.com which does not resolve externally - they should point to www: http://v3.corp.componentart.com/webui/demos/ajax/technique4/ should be http://www.componentart.com/webui/demos/ajax/technique4/

Posted on Fri Jan 25, 2008 @ 9:29 AM

Another quick question - why do the web service methods not need to be decorated with the [ScriptMethod] attribute (this is required, to my knowledge, for MS AJAX to create the client-side proxies). Also, is there any way to control whether it uses GET or POST? With the ScriptMethod attribute you can set [ScriptMethod(UseHttpGet = true)] To force the call to use a HTTP GET instead of POST. Obviously this might open your site up to certain security risks (which obviously need to be evaluated before doing so), but it's nice to have the choice..

Posted on Fri Jan 25, 2008 @ 9:29 AM

Hey Miljan, apologies, but I fail to see how this is new. For example, the good old AutoComplete that Prototype or ASP.NET Ajax have had forever seem to operate exactly using that technique: point them to a web service and you're in business. Am I missing something?

Posted on Fri Jan 25, 2008 @ 9:29 AM

Oops... You're right Steven, those were our internal development links. All links should work now. Thank you for pointing that out!

Posted on Fri Jan 25, 2008 @ 9:29 AM

Bertrand, I agree: we have seen this technique applied before - on a smaller scale and with simpler UI elements (like your AutoComplete example). What we have done is incorporate this functionality into our entire user interface framework - making it possible to build full apps with vast majority of the server-side logic implemented as a collection of web services. That's the new concept that we are trying to promote.

Posted on Fri Jan 25, 2008 @ 9:29 AM

To add to that comment, one thing I'd like to see (and I wish we'd done that ourselves, it has been suggested by a number of people such as Rick Strahl) is some form of lightweight callback where you just write an event handler on the server instead of a web service, but you don't have to pay for a full postback (no viewstate, etc).

Posted on Fri Jan 25, 2008 @ 9:29 AM

Bertrand, I think the real key here for *ComponentArt users* is that it completes the client-side picture. Yes, you are right, this functionality has existed elsewhere for a while. Likewise, ComponentArt's WebUI has had extensive client-side support for some time, but it has always depended on server-side data bindings. With the addition of the webservice bindings, the CA controls can be used without any server-side code at all. Miljan, I think the picture would be even more complete with some code examples showing off client-side creation of the controls with binding - that is, creating the grid, adding the grid levels, columns, etc. and then binding. I do have one concern about the usage of this - it seems that it is dependent on the client-side webservice proxies generated by the ScriptManager, which is great, except for the fact that the CA controls don't follow the MS AJAX page lifecycle. For example, the Grid's load event will fire before the Application.Init event. I can see myself running into issues where the Grid is ready, but the rest of the application that drives it is not. Do you have any comments/additional information about this? Thanks and keep up the good work - can't wait until v2008.1... I'm speculating on an upload control maybe?

Posted on Fri Jan 25, 2008 @ 9:29 AM

My biggest concern here is the amount of information that is otherwise now trusted to the enemy. The browser is in the hands of the enemy and the more business logic and databing client side, the more insecure the application is. While JSON databinding is nice, I am concerned about the myriad of security considerations when the presentation layer is no longer just the presentation layer.

Posted on Fri Jan 25, 2008 @ 9:29 AM

Bertrand, if I understand you correctly, our CallBack control (Technique #2 above) is exactly what you are looking for. A lightweight callback request, invoking an event handler on the server - without posting the viewstate. The event lives within the page life cycle and the developer gets to implement a handler for it to render the exact output for the AJAX response.

Steven, we will definitely follow up with you regarding the MS AJAX Application.Init event. The behaviour you describe shouldn't be happening. If this turns out to be a defect we will work on addressing it in the next service pack.

Posted on Fri Jan 25, 2008 @ 9:29 AM

Derek, you raise a great point regarding security ramifications of this new approach. When creating web services for this technique, it should be understood that they are there strictly for consumption by the client-side user interface tier. All security concerns should be addressed within the web service itself. In our example, browsing server directory structures outside of the application root of Web.UI demos is prohibited. This restriction is implemented within the web service itself. Therefore, it is not possible to create a request that will expose a portion of the file system on the server that's not meant to be exposed.

Please note that the other techniques covered above could also expose the same vulnerability, although this time the developer might feel a false sense of safety due to their server-centric nature and the fact that HTML is being generated on the server.

In general, applications developed using this new technique are not inherently more or less secure than sever-centric apps. However, I think they are inherently cleaner - emphasizing the exact end points that need to be secured.

Posted on Fri Jan 25, 2008 @ 9:29 AM

You're on to the path that I've been thinking about of what MS needs to do instead of MVC: Basically they need to re-work the page archetecture so that it stays stateful. That is there is never a postback, it's all done through ajax including submits and redirections. If the page_load was called once, and every control was responsible for all events going through ajax and rendering client side instead of how it does it now with post backs and sort of post backs, we would have a stateful system like Winforms that didn't have page life cycles etc. IT would simply call the event handlers and update everything there. Imagine how much more productive everything would be if we weren't constantly having to repopulate data and transfer everything all of the time? It would be great! Here's the the death of the isPostback test....

Posted on Fri Jan 25, 2008 @ 9:29 AM

Let's look at your suggestion. First off, http is a stateless protocol. It will never have state so we automatically have to get around that. Hence server side state management in ASP.Net. Any type of client side state management including ASP.Net ViewState is a potential security hazzard. Next is the whole notion that we're better off with a list of web services exposed to the outside world. I'm not sure I buy that given the amount of hackery that could happen if adding and deleting data are available through http web services. The security implications scare the hell out of me as well as the design implications. Typically, web services are created to execute a single well defined transaction. Most of the time these are functions like BlogPost_Insert() or GetUserInformation(UserID)... They are usually aligned with an atomic database transaction and then collected together to perform an Application Transaction. The general idea is to put a pile of these quick hit type methods in a Web Services library of methods that can be called from the client. Fantastic except you've now just published a roadmap to your backend systems. There's not much stopping a hacker with stolen credentials from writing his own front end application, violating lots of application integrity rules and wreaking havoc on your system. Ok so make web services perform application level functionality instead of database functionality. Now you'll run smack into a scalability issue. SQL Server/My SQL(even more so) is designed for short quick transactions. Sure you'll have the monster methods that take into consideration all the ways a method's interface could be called from the client but in the process you will have created a bunch of unscalable web methods that fight for database resources and web server threads. My point to all of this is that the Web Service idea imight be a great way to go but calling for the death of the postback is not only shortsighted but cripiling to the building of web applications. The faked session state has to be stored somewhere. You cannot and should not store or manipulate it on the client. So you have to have a postback mechanism in place. Besides with post backs you can take advantage of threading, connection pooling, caching, and the generally higher/more sophisticated amount of processing power available on the server that couldn't be done with a primarily client centered application. I'm interested in following this idea but it's really going to be about the implementation that sell me on it. ASP.Net has a very well defined page lifecycle. Its well documented, well understood and easy to debug once you understand how it works. The UpdatePanel modified little of this and added Ajax. To take the next step, Web Services over a CA custom Ajax calling method will need to be just as easy to use and every bit as functional as using the server side object. Example: We abandoned the Web Service populated treeview from the new CA release. ViewState was all messed up with it and after every postback the entire tree would collapse to the smallest node. There was no way to rebuild the tree on a postback because that would entail a client side recursive calling mechanism that would reexpand the nodes previously expanded before the postback. Because the web service methods only knew about one level at a time and did not update viewstate properly, we couldn't use the method. That ease of use has to be there for this idea to fly.

Tim

Posted on Fri Jan 25, 2008 @ 9:29 AM

I think MVC along with lightweight AJAX calls is going to be the death of the web service. Web services are just an unnecessary over-complication of a technology that was working just fine before it came along - HTTP. A web app is a web app. http://domain.com/Product/Edit/1 along with a form post is all the "api" you need. Want a JSON response, denote that in the header. Want XML, do the same. Wiring client side events to MVC controller actions is the future, not web services.

Julian Jelfs

Posted on Fri Jan 25, 2008 @ 9:29 AM

Miljan, I have three comments / questions. First, how is it possible with this approach to use a web service that have more complex security requirements? I would love to use this technique for all the reasons that you mention but my web services require a username password security token in the message (i.e. WS-Security). It seems likely that this approach will only support http authentication (i.e. security at the transport level). Secondly, why is still necessary to have a server control at all for the Component Art controls? I would really like to be able to completely create these controls from scratch on the client without having to have any markup on the page at all. Thirdly, what are your thoughts on Microsoft's MVC framework. This appeals to me a lot because I don't see a lot of value in the WebForms analogy any more but I'm concerned about how my third party controls (i.e. CA) can fit into the MVC framework. Thanks.

Posted on Fri Jan 25, 2008 @ 9:29 AM

I feel I have to agree with Derek here, the security issues about giving that amount of power to what's supposed to be only the presentation layer is very dangerous. Also it increases not only the attack surface but also the complexity. If you follow my link (yes I work for them) you'll see another approach that uses the controls on the server side and only comes with a very small performance hit compared to the WebService solution you talk about here but is equally secure as any conventional ASP.NET (postback) solution :)

JP

Posted on Fri Jan 25, 2008 @ 9:29 AM

It’s funny to me how classic asp would be written to "post" to itself with code testing a hidden value to determine which "state" the page was in before processing. Then .NET was released and did the same exact thing only wrapped with OO to check for "post back". The update panel with AJAX and now this "new" approach is still nothing more than the Sync / Async XML.HTTPRequest object of the classic day operated by client side code (VB or JavaScript). All this stuff is the same under the covers and is best when wrapped for universal use within the confines of the browser wars. If it returns to developers having to write client side, browser specific code (as in this case), the industry takes a step back. When this is wrapped for ease of use in the form of an "intelligent update panel", I will subscribe. I will take simple with a minor performance hit before an efficient maintenance nightmare. Don't get me wrong, I love the new tech and OO is the way, but we will always be subjected to the fact that the browser was never meant to be a GUI. It was designed as a reader without state, and we push it, and it pushes back. Cheers.

Posted on Fri Jan 25, 2008 @ 9:29 AM

I am excited to see that we have such an in-depth discussion here. Thank you all for your detailed feedback. I have read it carefully and it looks like your concerns fall into three categories: 1) security 2) performance and 3) application model. I'll expand on each:

1. Security

I think that most (maybe all?) security concerns will be addressed if I clarify one thing. We are not suggesting that you expose the web services you create in your data/application tier for direct consumption by the client-side UI. That would indeed publish "a roadmap to your backend systems" and would prevent you from using things like WS-security.

In all AJAX applications you have a finite set of operations that are accomplished through AJAX calls. The model we suggest assumes that you will create a collection of web services for consumption strictly by the client-side UI layer whose endpoints will correspond each AJAX operation you want to accomplish. This is still completely in line with the overall spirit of web services - executing a single well defined operation. Only this time the operation is related to updating a piece of UI.

There is nothing inherently less secure about this approach. In fact, we could even argue that the approach is inherently more secure because it clearly identifies the endpoint that is exposed to the client.

Derek, you note correctly that "any type of client side state management including ASP.Net ViewState is a potential security hazard." I absolutely agree. We don't maintain any state (beyond what needs to be displayed on the screen) on the client. More on that in the "application model" section below.

Obviously, this is an important topic. If you see any flaws in our logic we would definitely be interested in further feedback.

2. Performance

As stated in the whitepaper above, performance gains of this approach come from: 1) saving network bandwidth, 2) efficient server-side processing and 3) client-side UI optimizations. It appears that only point #2 is being disputed, so I will focus on that one.

The web service method will use the same database and threading resources as the same functionality implemented in a page codebehind. However, things like processing viewstate and the going through the page life cycle will be skipped - resulting in less server processing. I disagree that our proposed approach would result in "monster" web service methods. In fact, if you compare the server-side code for the two approaches, you will find that the page codebehind looks more monstrous: proper codebehind needs to determine whether the request is a) the initial GET request, b) a postback or c) an asynchronous postback. If an asynchronous postback, we need to figure out the purpose of that request and only execute minimal database operations required to process that particular AJAX request.

3. Application Model

"calling for the death of the postback is not only shortsighted but crippling to the building of web applications."

In that case, Microsoft is on a totally wrong track with their upcoming ASP.NET MVC framework! :)

Kidding aside, I think that both models have their place and serve a good purpose. The traditional postback-based model used by ASP.NET WebForms is powerful, intuitive and easy to use. The UpdatePanel AJAX approach perfectly fits into that picture.

The alternate MVC model - without postbacks/viewstate and with modified page life cycle - is being introduced to meet the needs of those who want perfectly clean separation of tiers, easier testability and top performance. State is no longer managed by the page, it is managed in the "model" part of the Model-View-Controller architecture.

We are quite excited by the upcoming ASP.NET MVC framework. The AJAX approach covered in our whitepaper could have an interesting application in the ASP.NET MVC model. More on that in another post...

A few of final notes:

Derek, the treeview problem you mention is a confirmed defect. It has already been fixed and will be included in the next service pack. Tim, I absolutely agree with you: REST-based API calls that return JSON are a great option. I guess that's another thing that needs to be clarified. When we talk about web services, we don't necessarily mean SOAP services returning XML. We use the term in a much broader sense. Julian, you are right: server controls shouldn't not necessary. However, they are convenient: they give you a nice way to define and configure the initial page layout in your ASPX code. JP, the JavaScript code you write with our products is simple, generic and cross-browser. It really comes down to using a few high-level API calls. Just refer to the example for technique #4. The entire client-side code to implement that file system browser is less than a screen full (with comments).

Thank you again for your keen interest and analysis. I hope that I have addressed all of your points and questions.

Posted on Fri Jan 25, 2008 @ 9:29 AM

Good work Miljan, we are seeing this as an increasing problem as more people start using (and over-using) UpdatePanel to simulate client-side behaviours. I blogged about this issue over on Asp.Net (http://weblogs.asp.net/joelvarty) where the viewstate and overall performance take a hit as you add more stuff to a page. In my opinion, this is where 3rd party controls like componentArt's can really capture the developer's attention, since databind lists of items to regular HTML elements is really tiresome. At the same time, the ability to have a trimmed-down version of these controls that is flexible and a little more lightweight on the client would be nice, too.

Posted on Fri Jan 25, 2008 @ 9:29 AM

Thanks for your response. I guess what I need to see is where the separation of application layers occur. As far as I understand it, in order to eliminate the postback, your client side application would need to inherit some level of application awareness. It would need to know more than just make this drop down visible if control A.Text == somevalue. It would need to know that it is performing an application transaction. Looking at the entire usage pattern for a site there's the initial HTML generation. This could use Web Services to get the markup for any number of controls. The user then interracts with the page. Eventually, they have to click a button that understands what to do with the data on the page. In the post back world, the entire page is posted back and the only thing that is sent along with the post back is the control/event name that caused the postback. The code for this event is securely in a server side ASPX page along with the knowledge of how to process it. In this scenario, in order to hack the page one has to comprehend the entire page to understand that fields X/Y/Z mean something to postback event A and even then its guessing because there's very little in the way of hints lying in the view source on the client. If the "Insert new database record" button fires a web service event then the client has knowledge of how to assemble the parameters on the page into a meaningful application transaction. That's where I think things get dangerous by increasing the surface attack area of your web site. How do you avoid giving the client information on how to assemble an Insert new database record application transaction? Will your Web service calls be nothing more than the control/event name that triggered the postback? I can't imagine that being the case because then you've left the control state/View state on the client and the web service doesn't know about it. Maybe I'm just being stubborn in thinking that the only way to build the web service call on the client side is to also tell the client side how to organize the data in the controls of the page to make the web service call and that seems to be walking down a dangerous path. In server side objects, you pass back all the data and that presents the client side user with an obscured view of your backend system.

Julian Jelfs

Posted on Fri Jan 25, 2008 @ 9:29 AM

Miljan, thanks for the responses but I'm not sure that you have addressed the specific problem that I have which is this. If I have a web service that is callable from the client it absolutely must be secured using WS-Security username password tokens in the message header (I cannot use integrated windows authentication and I cannot have anonymous services returning business data). If there is not a way to call a web service with such a security requirement from the Ajax controls then I cannot use them. I don't necessarily mean this as a criticism because I have yet to find any javascript library that does make this sort of thing workable - I'm just seeking clarification that I am not missing the point.

Posted on Fri Jan 25, 2008 @ 9:29 AM

You are right, Derek - it's going to come down to clearly identifying the separation of application layers. We will try to provide more elaborate examples of this approach. Hopefully that will help clarify these concepts. In the meantime, you can approach this technique by evaluating whether you can replace traditional AJAX requests in your application with web service calls. Julian, the previous sentence also applies to your question. If your existing web services absolutely must be secured through WS-Security then you shouldn't try to invoke them directly from the client. You would most likely invoke them in the middle tier. Since you need to provide some of that data to the user interface tier eventually, we recommend creating new, non-authenticated web services to serve the UI tier. Their purpose is strictly to replace your existing (non-authenticated) AJAX calls. You don't gain or lose anything when it comes to security, but you do gain quite a bit in performance and responsiveness.

Posted on Fri Jan 25, 2008 @ 9:29 AM

Don't get me wrong. I see the value of client side Ajax calls. We're using them with your components today. My biggest concern with all the hype over client side programming applies just as much to ASP.Net MVC (What little I've read of it) as it does to any other Ajax library. They are all fantastic approaches to web site design but they are not the silver bullet. From my experience in game development, I can tell you that as soon as you allow the client to do anything real, its a security problem. No real criticism of the way you're moving with the CA product line because I am curious as to how this all evolves and how it plays with ASP.Net MVC. Very interesting discussion though.

Stephen Woolhead

Posted on Fri Jan 25, 2008 @ 9:29 AM

Could someone point me in the direction of any documentation on this? I have a basic example working, but what I really need to do is round tripping a cache key between the aspx page and the webservice. I have a very expensive to create data set that is in a cache and I need to pass the cache key to webservice. I see that there is a CustomParameter on GridWebServiceSelectRequest that would suit my needs but I have no idea how to get the data in there in the first place!

Posted on Fri Jan 25, 2008 @ 9:29 AM

Nice, will it be lightweight loading

Shahid

Posted on Fri Jan 25, 2008 @ 9:29 AM

Checking the New Compnents

Posted on Fri Jan 25, 2008 @ 9:29 AM

So ... if I grok the security sections of the above exchanges correctly, Miljan advises that direct invocation of web services secured by leveraging message header-based security techniques should be accomplished by wrapping those web services with web services intended to bridge between the UI (so HTTP headers can be processed) and the middle tier (where custom message headers can be managed). Is this correct? Thanks, Tom

Posted on Fri Jan 25, 2008 @ 9:29 AM

> what I really need to do is round tripping a cache key between the aspx page and the webservice.

Stephen, with Web.UI 2008.1 we standardized client-side events relating to web service calls across this group of controls, and added the ability to pass custom data to and from the web services. Each *WebServiceRequest and *WebServiceResponse class now has a CustomParameter property. Please see the following blog post for details.

> Miljan advises that direct invocation of web services secured by leveraging message header-based security techniques should be accomplished by wrapping those web services with web services intended to bridge between the UI (so HTTP headers can be processed) and the middle tier (where custom message headers can be managed). Is this correct?

Tom, yes - that's correct.

Khurram Shehzad

Posted on Fri Jan 25, 2008 @ 9:29 AM

There is no doubt that it’s a great technique. But I am bit sceptic about it even though I have used it a lot. First reason is normally web applications should be agnostic to the client. The execution of a web application should not be dependent on the client’s machine. With these techniques loads of JavaScript files are executed on the client that consumes memory as well as processing. So clients with different machines won’t have the same experience. On top of that if the applications are not carefully built there can be memory leaks on the client side (mainly due to references between JavaScript objects and DOM elements). The other big concern as indicated by many is security. A classic web application is like a single door house while an Ajax application with web service call backs is like a house with many windows. So securing it all can become a tedious job to do. All in all if carefully used it can provide a really good user experience and that’s what really counts at the end of the day.

Chris W

Posted on Fri Jan 25, 2008 @ 9:29 AM

Can't you protect json webservices called by the client browser with forms authentication and coding againt user.identity.name ? Wouldn't the non-authenticated public be locked out if so?

Robb Melancon

Posted on Fri Jan 25, 2008 @ 9:29 AM

Although I like the speed of the Web Service approach, I still hate the flashing of the page everytime something is updated. I would prefer a slight wait with a progress bar (method 2) over the "postback" flashes.

Duy Tran

Posted on Fri Jan 25, 2008 @ 9:29 AM

Dear all, Can you help me my problem in VS2008 and componentArt lastest version? I use MultiPage with Menu: this my code, I buil Muitipage from data: In HTML, I use Updatepanel: In Code: private void buildMultiPage() {ClsCommon CLS = new ClsCommon(); DataTable ds = new DataTable(); ds = CLS.OpenDataTable("Pro_SECURITY_MENULIST @Activity = 'BuildMultiPage'"); for (int i = 0; i
Code: protected void Button1_Click(object sender, EventArgs e) { TextBox1.Text = "This is User control"; } When I run Program,I can buil muitipage with load User Control, but when I click on first time: Button1_Click, it not run, Textbox1 don’t load new string. If I continue click again in button, my Muitil page will hide (Visible=false), Can you help me -if I Move UpdatePanel to Usercoltrol:
My problem still load good, but but when I click on first time: Button1_Click, it not run, Textbox1 don’t load new string. If I continue click again in button,my propram will Postback and my Muitil page will hide (Visible=false), Can you help me? *Impotant; In my program, I want use Muitipage load usercontrol, in my user control, I code all code with ajax. I don’t want my propram Autopostback. Please help me fix this problem or if you have some code example load usercontrol in Muitilpage or have some way else, plese help me soon. Wait your anwser! Thanks and best regard! Duy Tran

Posted on Fri Jan 25, 2008 @ 9:29 AM

excellent articlesw about ajax control.
Click here to log in or create an account.