Curl Blog

Previous Next
Click to view jnan's profile
24

Recently I read in a blog that the Enterprise 2.0 will be a $4.6 Billion industry by 2013. The post also mentions the hurdles in adopting Web 2.0 technologies by the large companies. The article said:

For vendors specifically, there are 3 main challenges to becoming successful in this new industry, including:


  1. I.T. shops being wary of what they perceive as "consumer-grade" technology
  2. Ad-supported web tools generally have "free" as the starting point
  3. Web 2.0 tools will have to now compete in a space currently dominated by legacy enterprise software investments

As I have said before, the fastest way for Web 2.0 adoption will be via RIA (rather than the more popular ones such as wikis, blogs, tags, mashups, and social networks). RIA is the low hanging fruit where users get an enriched experience compared to the client-server implementations of yesteryears. The TCO (Total Cost Of Ownership) of RIA is also compelling.

Why do I say this?


Let me give you five examples of "actual RIA applications in use" by very large global companies using Curl RIA platform. This follows my post few weeks ago on the key requirements for enterprise RIA.


Example 1 - Voice of the Engineers (VOE) - Large electronics manufacturer built a real time application to link the field input to parts repair information. This application provides rich graphical interface to visualize suspected points of failure. Executives can also get aggregate information on failure trends over time (classic BI). Benefits are quantified in several hundreds of thousands of dollars of cost saving in the first year of implementation.


Example 2 - Heatmaps - Significant company in the GRC (Governance, Risk, Compliance) space offers a Curl-based RIA to its customers. Grid-like UI offers a view of various business units that pass or fail compliance. They call this the Heatmap. As you mouse over to the red cell (showing compliance failure), further details are revealed as to why. The company claims this specific visualization is the big competitive differentiation for them. They are growing briskly at 40% year to year in this space.


Example 3 - Procurement - A large international company (household name) in the electronics manufacturing business built a procurement system using Curl front-end technology with Oracle DBMS and J2EE backend. The systems has been in operation or 3 years with over 300 users. Very large data volumes with fast performance was the key need. Benefits are quantified as 50% reduction in cycle time compared to the same under the legacy client-server system.


Example 4 - Consolidated Billing - Large telecommunications company built a consolidated billing system (for landline, VOIP, long distance, cell phone) for corporate clients. The old system was built using Visual Basic and bills were sent via CD's causing delay in data upload and services. The new system uses Curl in the client-side and Oracle in the backend. Currently 10,000 clients use the system, likely to grow to 15,000 next year. The entire application was developed within a year on a budget of $1M. Benefits include 10% in cost savings with increased accuracy of data.


Example 5 - Insurance planning for agency - Large insurance company offers this web-based application for agents. It can simulate customer's financial's, trying various policies of the plan and provides visual results with graphical charts for easy understanding. This new Curl-based system replaced the old Visual Basic system. The client states the benefits as: easy maintainability, better security, better performance and no data latency.


There are many more such examples from Curl's 300 plus large enterprise clients.


Hence we humbly claim Curl to be the defacto leader in Enterprise RIA space.



Add a comment Leave a comment on this blog post.
Jun 15, 2008 1:47 PM Reply Guest Charles Kendrick

I'm sorry, but I really think this 'defacto leader' claim is playing games with definitions.

If you define your RIA competitors as Silverlight and Flex, you are picking two very recent technologies with limited time to build up a deployment base.

If you instead compare Curl to Ajax platforms with RIA capabilities, there are at least 3 Ajax RIA platforms which have much broader deployment and have been used for applications as sophisticated or more sophisticated than the examples you name, specifically SmartClient, TIBCO GI, and Bindows. You could arguably add Dojo and ExtJS as well.

It would be a huge mistake for an enterprise to define RIA in such a way as to exclude Ajax RIA platforms. Ajax is the only fully standards-based RIA approach, Ajax has the broadest installed base, and the 4 major browser vendors are in a war to provide the fastest, most capable platform for Ajax.

Jun 15, 2008 5:33 PM Reply Click to view jnan's profile jnan in response to: Charles Kendrick

Charles,
Appreciate your comment.
Ajax has been proven grossly inadequate for enterprise class RIA deployment. In an independent study done by Sonata Software last year (same application implemented via Ajax, Flash, and Curl), when number of records exceeded 50,000, Ajax-based application just stalled and could not handle the load. We are not talking about a "pop-up" window implemented via Ajax here. These are serious transactional stateful and highly interactive application of the cadre of client-server apps. for business critical functions. But so far, we don't see any real implementations of such applications in Ajax. During the last Ajaxworld in March 2008, speaker after speaker deplored the inadequacy of Ajax(specially scripting and DOM) for enterprise-class RIA (poor performance, vulnerability to XSS attacks, lack of scalability,..).
Also, I do not know what you man by "sophisticated application". These large corporations are building mission-critical applications on the web platform with better GUI and capabilities to handle large volumes of data, better scalability, and super-fast performance, and offline execution. This goes well beyond what browsers can provide. As a matter of fact, the new trend is to render such applications outside the browser (e.g. Adobe AIR, Curl Nitro, Google Gears, Mozilla Prism).
Jnan

Jun 16, 2008 2:27 PM Reply Guest Charles Kendrick in response to: jnan

1. Sonata's report was about ASP.NET Ajax specifically, which is not an Ajax RIA platform. It does not indicate anything about Ajax RIA platforms, which handle large data volumes with ease.

2. Comments about "Ajax" in general are meaningless, only comments about specific Ajax platforms can have meaning, as they are so varied. SmartClient in particular avoids any DOM access, and all Ajax RIA platforms provide object-oriented approaches, not "scripting".

3. By sophisticated applications I mean for example Informatica PowerAnalyzer, where SmartClient provides dynamic navigation of multi-dimensional data cubes, visualization of metadata integration flows, and on-the-fly testing of WSDL web services.

4. Offline capability is available with Ajax platforms, and SmartClient in particular ships with offline examples

5. Ajax security vulnerabilities are a myth propagated by non-experts who do not understand the distinction between Ajax as an attack technique and vulnerabilities related to use of Ajax. It has been soundly debunked by experts in the field:

http://www.whitehatsec.com/home/assets/newsletters/WhiteHatNewsletterDec06F.pdf

Jun 17, 2008 5:29 AM Reply Click to view jnan's profile jnan in response to: Charles Kendrick

You have to glorify the platform you are promoting, hence your comments don't surprise me. But I am not the one saying the inadequacy of Ajax platforms (over 200 of them). It's many many people out there. It's a fact that enterprise RIA and Ajax platforms are oxymorons, notwithstanding your example of the Informatica cube (I will check with Markarian, CTO and Sohaib Abbasi CEO, both former colleagues at Oracle).
We will let it stop here. Let the market decide what RIA technology finally wins. Curl happens to have 300 active large customers and I am not familiar with SmartClient. Your offline offering is interesting and one wonders how you can do that if you render it as part of the browser.
Anyway, good luck and let the market decide.

Jun 17, 2008 5:34 AM Reply Click to view cbarber's profile cbarber in response to: Charles Kendrick

Ultimately, any AJAX implementation is limited by the poor performance of JavaScript in your browser. JavaScript is several factors of magnitude slower than Curl or even ActionScript. There is simply no way around that. And while it is true that JavaScript is "object-oriented", it does not use the class-based statically inheritance style of object-orientedness that C++/Java/C# programmers will easily understand.

Jun 17, 2008 12:06 PM Reply Guest Guest in response to: jnan

@jnan

In fact I am not glorifying SmartClient, but pointing to a list of technologies (again TIBCO GI, Bindows, ExtJS and others) all of which have been used for Enterprise RIAs for years. You could talk to Informatica, or could look at a host of other resources that point to Ajax RIAs in use and succeeding: take a look at TIBCO GI's case studies, or ask other Oracle colleagues about Bindows being used in Hyperion's BI product line. Or look at the many public Ajax RIAs: Gooogle Calendar, GMail, Flickr, Yahoo Mail, etc.

"It's a fact that enterprise RIA and Ajax platforms are oxymorons" - this simply isn't true, and the evidence is everywhere.

Jun 17, 2008 12:14 PM Reply Guest Charles Kendrick in response to: cbarber

@jnan (obviously, Guest was me)

@cbarber: you may not be aware that Adobe's ActionScript engine has been donated to the Mozilla foundation and it's performance enhancements are being rolled into Firefox:

http://www.adobe.com/aboutadobe/pressroom/pressreleases/200611/110706Mozilla.html

Firefox 3 already delivers dramatic performance improvements, but Safari 3.1 has now leapfrogged it by another 53%:

http://www.tgdaily.com/content/view/37904/113/

There are no inherent limits to the performance of JavaScript and the browser vendors are in a race to provide the fastest possible engine.

But, bigger picture: what matters is the entire software lifecycle, not just performance differences. Ajax as a technology already has more than enough performance to deliver a wide range of RIA applications, it's getting better all the time, and there are many systemic advantages to Ajax in terms of it's greater reach, openness as a platform, and the ease of integrating with other technologies.

Jun 17, 2008 12:40 PM Reply Click to view cbarber's profile cbarber in response to: Charles Kendrick

I fully expect ECMAScript 4 will eventually make its way into all browsers. But it will be several years before anyone will be able to assume that it exists in most people's browsers. I love FireFox, but it still owns just a small fraction of the installed browser base. Once you start forcing your customers to install a particular version of a browser for your AJAX implementation to work, you eliminate the advantage of AJAX over plugin-based RIA solutions.

Furthermore, upgrading to the new version of JavaScript is not going to make your code faster. You need to actually start using static typing in your code, which will require you to rewrite all of your existing JavaScript. Even at its fastest, ActionScript is still much slower than Curl and JavaScript will be no different.

This is not to say that some day there might not be a version of browser-based JavaScript comparable in power to Curl, but that won't come for some years yet if indeed ever.

Jun 17, 2008 12:58 PM Reply Guest Charles Kendrick in response to: cbarber

@cbarber
Bigger picture, when Firefox and Safari provide speed boosts, Internet Explorer must match them or lose yet more ground to these other browsers.

IE7 is dramatically faster at JavaScript than IE6, and Microsoft in fact rolled IE6 JavaScript optimizations into an XP service pack to bring it closer to IE7. This trend will continue.

But again, bigger picture: performance is just one aspect of a successful RIA. Once you have demonstrated that sufficient performance is there to handle your use case, other factors should drive the decision, such as: extensibility, flexibility, integration with other systems, reach and installed base, the ability to upgrade incrementally, skill sets and available talent, closed vs open systems, etc. To look at performance only is to miss the point.

Jun 17, 2008 1:05 PM Reply Guest Charles Kendrick in response to: cbarber

@cbarber
Sorry, one more misconception: all of the recent speed boosts to IE, Firefox and Safari increased the performance of existing Ajax applications in the field, and there will be further, large speed gains that will likewise not require code changes.

Leveraging ECMAScript4 will require some core changes, however, Ajax platform vendors will have the ability to improve the speed of the core platform without requiring application code changes. So existing applications will be boosted, without code changes, by upgrades to a new, backwards compatible platform runtime, similar to any upgrade of the Flash or Curl player.

Jun 17, 2008 1:08 PM Reply Click to view cbarber's profile cbarber in response to: Charles Kendrick

Making existing JavaScript code run 50% or even 100% faster doesn't help much when it is a hundred times slower than Curl. You won't get even close without using static typing.

Jun 17, 2008 6:15 PM Reply Guest Charles Kendrick in response to: cbarber

I'm not sure how to say it any plainer: speed is just one trait of a technology, and not the most important by far.

Ajax does not have to be faster than Curl to be the best choice for very, very broad range of RIA applications.

Ajax just needs to be fast enough to provide a great user experience (which it is) and it needs to have other, substantial advantages (which it does).

Furthermore, language-level performance is not a good predictor of overall application performance. In practice, architectural advantages such as incremental loading and incremental rendering matter more, because they allow an application to work with arbitrarily large datasets. When you work with not 50,000 but 50 million records, as is the case in some SmartClient applications, linear speed differences no longer help, only the architecture counts.

Jun 17, 2008 6:28 PM Reply Click to view RMH's profile RMH in response to: Charles Kendrick

I think that Charles has some very good points. Raw speed will only take you so far. In the end its up to end-users to choose which RIA Platform that they want to use. Be it Curl, Flex, Silverlight, SmartClient ... whatever. The best we can do is talk about our own strengths without disparaging other products. Charles, if our evangelism of Curl at the expense of Ajax has offended you than I apologize. Like you, we are passionate about our platform and sometimes we get a little aggressive. Anyone that wants to check out SmartClient should do so (http://www.smartclient.com/). Actually you should post a code snipplet up and compare it with JavaFX, REBOL, and Curl in the "How big is your source code" blog post.

How big is your source code?
http://developers.curl.com/blogs/community_blog/2008/06/12/how-big-is-your-source-code

That's a comparison that is intended to be fun.

Jun 18, 2008 7:36 AM Reply Click to view cbarber's profile cbarber in response to: Charles Kendrick

You are right. AJAX may be the best choice for some applications, namely those in which you cannot assume that you may install any plugins or other software on the client. There is no question about that. And it is still a very good choice for less restrictive domains as well. But in an Enterprise setting where IT departments control the installation of software it is generally not a problem for them to install software; they do it all the time.

You are also totally correct that for many performance issues the architectural design of the system and choice of algorithms is more important than the performance of the platform. But given the same algorithms and architecture, the platform performance can and often does matter. In cases like that, you want to be using something like Curl.

AJAX has no advantage over Curl with respect to incremental loading or rendering. Curl supports both. As with browser-based JavaScript, full support for processing Curl source code is available on the client, so the full power and flexibility of the language is available at runtime. This differs from VM-based approaches such as Java or ActionScript in which the code is compiled into some form of byte code and no compiler is available on the client. The difference between JavaScript and Curl is that the former is an interpreted language while Curl is compiled. This makes a huge difference to performance. Eventually, I would expect to see better support for compiled JavaScript in browsers which should help a good deal, but it will take another couple of years until it is widely available on all major browsers and free of vendor-specific implementation quirks.

While I believe that Curl will continue to hold a performance advantage over JavaScript/ActionScript, I fully expect some other RIA platform to match our performance at some point, so that cannot be the sole reason to choose Curl. Personally, I think the biggest advantage of Curl is the Curl language itself together with its set of built-in libraries.

Jun 18, 2008 12:34 PM Reply Guest Charles Kendrick in response to: cbarber

Our experience with introducing plug-ins into enterprise IT shops has been the exact reverse - because every plugin increases the chance of security vulnerabilities and is more to manage and update, enterprises are loath to introduce new software.

Software vendors selling enterprise products are particularly sensitive to this, because they don't want to fight a battle with IT every time they make a sale. We have one software vendor customer who built a Flex-based product and re-wrote the entire product with SmartClient when they went to market and found it was difficult or impossible to change IT policies at key prospects. And that was just because of a requirement for Flash 9, not something like Curl.

Not to mention, the enterprise intranet is not the closed environment it once was. Intranet applications are frequently repurposed as extranets, and when you expose an extranet to partners or customers, you have the same issues a software vendor has - you don't control IT policy at your partner or customer. You really, really don't want to end up with two software stacks - one for external apps and one for internal - with two parallel sets of staff and two parallel infrastructure investments.

As far as incremental loading or rendering, it's good to hear that Curl does not have Flex/ActionScript's limitation here, but you didn't take my point. Language-level capability is not the same as actual, ready-to-go components.

For example, SmartClient has a CubeGrid component that can do bidirectional load on demand as well as metadata load on demand with a cube data model provided by any sort of data provider (WSDL, SQL, REST, etc). Curl has a customer-specific BI demo with no code provided. I don't have a comprehensive view of the Curl product, but in this particular area, the two technologies are man years apart architecturally in terms of the data volumes they can tackle out of the box.

Just to beat the dead horse of performance one more time: usability studies show that humans using software describe any response under about 100ms as "instant". This number is rooted in human physiology - you can be disqualified in Olympic sprints for starting less than 100ms after the gun, because that's not physically possible, so they know you jumped it.

Ajax - at least, SmartClient - provides this "instant" response routinely, and faster than "instant" has no impact at all on user experience. OK, dead horse beaten :)

Jun 18, 2008 1:05 PM Reply Click to view cbarber's profile cbarber in response to: Charles Kendrick

You are correct that some Enterprises are paranoid about plugins. Of course those same Enterprises are also paranoid about new versions of browsers so they will be the very last to take advantage of improved JS implementations. Needless to say, we don't kill ourselves trying to sell to such clients ;-)

I can see people getting a little worried about security issues with Flash since there have been multiple exploits against it in recent years. That same concern should not apply to Curl, not only because it is much harder to attack, but also because it is not widespread enough to be an interesting target for evil hackers.

I think that having a good set of code libraries is indeed important. Curl already has a very large set of standard libraries. The set of libraries that are installed with the RTE are considerably larger than any other RIA's standard libraries, but you are correct that the more libraries the better and that is something we are always working on. I am not an expert on our higher-level libraries, so I will let other people comment on how we stand regarding a CubeGrid-type component, but I rather doubt we are "man years apart" nor that their is any extra architectural limit to data volumes Curl can support.

Jun 18, 2008 1:30 PM Reply Click to view rhh's profile rhh in response to: Charles Kendrick

Charles,

Regarding the use of RIAs for a company to interact with its partners, suppliers, and customers, you have your anecdotes and we have our anecdotes. There absolutely are several Curl enterprise customers who are very happily using Curl-based applications for this kind of extranet B2B (or, in some cases, B2C) service. They have not reported that the need to install the Curl RTE at their user sites was an obstacle to acceptance of their applications.

-Bert

Jun 18, 2008 2:15 PM Reply Guest Charles Kendrick in response to: rhh

Bert, certainly, it won't happen every time with every customer or partner. Perhaps it's also less common in Japan.

However, what is not an anecdote is that all the major ERP suites use Ajax (Oracle including PeopleSoft+JD Edwards, SAP, Infor, Sterling), with occasional Flash for things like charts, no Curl. All the major CRM suites, likewise. All major PLM suites. All major SCM suites. All major PIM/collaboration suites. Correct me if I'm wrong.

The rare exception, like say Flex-based Coghead, is aimed explicitly at the midmarket. At a certain level of scale, you encounter IT restrictions all the time.

Jun 18, 2008 3:18 PM Reply Guest Charles Kendrick in response to: cbarber

@cbarber
This is a huge claim: "set of libraries that are installed with the Curl RTE are considerably larger than any other RIA's standard libraries". Can you back it up? Recall, Ajax is a RIA technology and SmartClient and other engines add several thousand APIs to the browser's already rich runtime. Then there's Java Web Start, clearly a RIA technology, which dwarfs Curl.

As to Cubes and data volume limits: no general purpose programming language has long term limitations in handling large data volumes, but it's about what you can do today. Multiple man-year gulfs exist between many products in many specific areas, it's perfectly plausible. If you are so inclined, compare the two quarters required to build your BI demo to our CubeGrid and Charting demos and see what you think.

Jun 18, 2008 3:23 PM Reply Click to view jnan's profile jnan in response to: Charles Kendrick

Saying some old school ERP packages use Ajax will not make them Born-again RIA's. Their client-server pedigree is too easily visible, hence the lack of flexibility, etc. My discussions with SAP, Oracle, etc. have clearly shown that Ajax is not their future course, only used for atomic features like a pop-up here and there. They are seeking better alternatives, as we speak. BI vendors clearly favor Flex over Ajax and even then they mention tons of limitations. So please don't make sweeping declarations that the entire universe of SCM, ERP, CRM, PLM and BI have overwhelmingly endorsed Ajax. Not true at all.
We tend to see the world through the limited lens of our biases.

Jun 18, 2008 7:18 PM Reply Guest Charles Kendrick in response to: jnan

You don't seem to want to contradict what I actually said :) .. which was that all of the existing, leading offerings use Ajax with occasional Flash, and that this has strong implications as to the importance of reach (zero-install deployment) in selling to large enterprises. These companies chose Ajax when it was much less mature than it is now, when Curl had been available for years.

The limited inroads made by Flex - a much more recent, and, as you say, less capable technology than Curl - only serve to emphasize the importance of zero-install deployment. Flex obviously has much better reach than Curl, even if they have serious issues with Linux, Solaris, mobile, and requiring days-old versions of Flash. But even with the greater reach of Flex, from what I've seen, the adoption of Flex in large enterprise products has been limited to 1) a parallel offering to an Ajax interface 2) niche use of Flash/Flex embedded in an Ajax UI.

No, SAP and Oracle's use of Ajax is not "atomic features like a pop-up here and there" - I'm sorry, that's just incorrect, I just hired a Senior Product Manager away from Oracle and I really, really know whereof I speak. Oracle's flagship web UI technology is Oracle ADF, a JSF-based Ajax platform, and that's what they told people to use at AjaxWorld.

Take a look at some Oracle or SAP product demos - SAP Netweaver Portal, or again anything with Oracle ADF - you'll find pervasive use of Ajax, some of it very sophisticated: cube models, drag and drop, etc. And they are cranking away at making it better.

Meanwhile, there have been recently been major new strategic commitments to Ajax technology at other top enterprise product vendors. Not discussions. Licenses. Product cycles starting. Look at customer lists of Ajax RIA vendors, the information is there.

Ajax is a viable and established enterprise RIA technology. If y'all could stop dropping bombshells, maybe we could end this discussion in agreement on this simple, and I hope by now, non-contentious statement? Cheers.

Jun 19, 2008 8:28 AM Reply Click to view cbarber's profile cbarber in response to: Charles Kendrick

I think you misunderstand my claim about installed libraries. When you install the Curl RTE onto a client machine it comes with a large set of libraries which application developers can assume are already present and do not need to be downloaded along with the application. AFAIK, AJAX solutions can only assume a much smaller set of libraries being already present on the client. Other standard plugin RIA platforms also have much smaller sets of libraries.

You are correct Java Web Start can be considered a sort of RIA technology for although I do not believe that simply installing web start gives you tons of libraries. No doubt someone could configure a custom installation with an arbitrarily large set of libraries. If you compare Curl to something like that, then you are correct.

Jun 19, 2008 11:56 AM Reply Guest Charles Kendrick in response to: cbarber

@cbarber
I think I really don't understand what you mean and would like to..

An Ajax RIA platform delivers it's runtime dynamically as a set of .js files which are then cached by the browser for future accesses. Typically the runtime is divided into modules which a given application may load or not load. If an application upgrades the runtime, this is transparent to the user. If an application begins using additional modules, those new modules are downloaded transparently and added to the browser cache. If two applications use two different versions of the runtime, they are just separately cached, again transparent to the user.

I'm not sure how Curl is different - are you saying, a lot of libraries are installed with Curl, so they don't need to be downloaded when the application is accessed? If so, how do you handle versioning when different applications need to use different versions of the platform?

Jun 19, 2008 12:15 PM Reply Click to view cbarber's profile cbarber in response to: Charles Kendrick

Yes, that is what I am saying libraries are included in the installation of the Curl platform on the client. Each version of the Curl platform includes its own set of libraries, i.e. we do not share built-in RTE packages across versions.

Additional Curl packages in source form may be downloaded on demand, and are compiled to machine code and persistently cached in binary form so they do not have to be downloaded or compiled when they are used again. This allows you to build Curl applications consisting of literally hundreds of thousands of lines of code and get fast load times. The Curl IDE itself is an example of this, which consists of ~170K lines of Curl code. It is shipped in compressed source form and compiled and cached when the IDE is installed. Once installed, the IDE starts in seconds.

Popular Blog Posts