Ajax and Leaky Business Logic

Dietrich Kappe, Thursday, April 27, 2006 @ 9:00 am

I gave my presentation last evening to a welcoming Chi2 audience. The attendees were a good mixture of developers, designers and business folks. They sat through my rantings on why I thought Rich Interaction Applications (RIA) in AJAX should be developed with server-side component based GUI's, though, in a pinch, I could see the argument for client-side component based GUI's that use the back-end as a dumb data web service. Then I showed them what 150 lines of Java code could do in the Echo2 framework with my special "why would you do things this way" stock quote app. Lot's of dragging and dropping ensued.

I'll put the presentation and the demo up when I get a chance.

One of the more interesting and probing questions after the talk was about business logic leakage, i.e. how does a server-side component GUI (SGUI) keep you from leaking business logic? The answer is simple: with the SGUI, the only "logic" that makes it to the browser is "turn this area blue," "move this button over here," and "make this element draggable." While I suppose it is possible to leak business logic in this way, I'd have to say that the possibility is pretty remote and esoteric, akin to sending smoke signals.

In the pseudo hand-coded world of traditional webapp development, you are dependent on developers following good practices and not making mistakes, such as leaking the secret sauce in their Javascript validation logic. At least you hope they do. If the last 50 years of software development practice have taught us anything, it's that hope is not a plan.

There are two kinds of information leak -- what and how. "What" is your customer data, your orders, your accounts receivable, your employee database. The "how" is your secret sauce, the special way of pricing or quoting or doing that gives you a competitive advantage. Reports can leak the "what," and many businesses can survive a leak of quite a bit of "what," but leak the "how," your secret sauce that makes you money, and you're cooked. Javascript can leak the "how" if you let it.

Michael Mahemoff feels it's sometimes OK to include business logic in the Javascript:

I realise there are plenty of problems with Javascript business
logic, and it’s certainly not always applicable. Those problems include:

• Security - Exposes business logic algorithms and enables them to be changed.

That first bit applies to most all valuable services that a company might provide. If all you're providing is data, then no business logic would be leaked. If you are performing some sort of business logic on the data, it would have to be something pretty trivial to still have value and not be a divulging of the crown jewels. Can a business consist of a bunch of ultra trivial, obvious logic and still be competitive? Probably not. In short, I can't imagine the circumstances where that first item wouldn't just preclude exposing most any business logic.

agile ajax

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Assuming that one does a good job of keeping business logic on the server, then there are (at least) two approaches to complex browser-based UIs. One would be sending UI update commands to the client (which is what I think you mean when you refer to SGUI) and another approach would involve shipping the post-business logic model data to the server (as JSON or XML) and letting the javascript client be smart about how to deal with it. Obviously, sending UI component update commands to the browser makes the “what” harder to extract for anyone trying to scrape the site. But then again, by passing UI update commands back to the browser, then you’ve introduced a dependency between your server code and your client code which means every change to a client could require a change to the server. Anyway, I’m curious…where would you recommend drawing the line?

   Comment by scott, Thursday, April 27, 2006 @ 2:07 pm

2. 

   I’m not sure it matters where you draw the line here. The two scenarios are similar enough as to make the decision a practical implementation question. Either you are shipping DOM update commands to the client side engine, or you are shipping data which the client then processes into DOM updates.

   Nothing precludes your framework from implementing something like this. For example, the classic MS data grid could be implemented either way.

   The real concern is where to draw the line with regard to the business logic. Sadly, the trusted environments where you could use client-side logic usually have the best performance, while untrusted, remote environments usually have the worst.

   Comment by Dietrich Kappe, Monday, May 1, 2006 @ 4:34 pm

3. 

   Storing of rules in the browser is a big concern for many IT folks. SmartForms for Blaze Advisor is one product, though there may be others, that can address this while still providing a rich rules-driven interaction. The rules in SmartForms are not visible on the client because the rules are compiled into XPath expressions loaded into memory. The users can not view the source. SmartForms does not generate any JavaScript code for a specific form. The output of the Smartforms is a set of XForm pages+ XSL transforms and CSS files. No JavaScript is used for rule enforcement; rather SmartForms uses the XForms constructs and the XPath expressions for validation and rule enforcement. Using this design approach no validation logic is exposed to the client. End users will not be able to see the validation logic because the logic is managed by the form models which reside in the browser memory, The only information that an end user would be able to see are the compiled XPath statements and XForm constructs and the constructs can mask these as well.
   http://edmblog.fairisaac.com/weblog/2006/05/business_rules_.html

   Comment by James Taylor, Wednesday, May 10, 2006 @ 5:45 pm

Leave a comment