First, let's excerpt the abstract to tee things up:
Ten years have passed since the W3C initiated its effort to design a query language for what, in 1999, was a new and controversial semi-structured data format, namely XML. A decade (and a lot of effort) later, the (now programming) language and its implementations are finally reaching industrial strength and are being taken up by customers as a solid alternative for building complex applications.Because, as Daniela points out, cloud is orthogonal, I'm not going to explore that angle here. (But promise I will in the future as I agree that XQuery in the cloud is a great idea.) Instead, I want to focus on the transformative power of XQuery on web application development.
Meanwhile, independently of the development of XQuery, and completely orthogonal to any programming language or application development infrastructure, a new buzzword is becoming more and more visible in the IT arena: the "Cloud." In this talk I will describe the poor state of current application development, which has serious limitations and inconveniences, and I will explain why, today, innovation in this area is unavoidable. The applications bubble is about to burst: existing software components, architectures, programming languages, database models, and communication protocols are under significant pressure to change.
I will argue that a combination of those two important technologies, "XQuery + Cloud," might provide a breakthrough in the area of application development infrastructure.
Frankly, when most people start to use MarkLogic they don't do so because of the potential to transform application development. They come to us because they are having trouble storing, searching, querying, and delivering XML content or semi-structured data. Only after they have built a few applications do they realize -- hey, wait a minute, I could build my entire application in XQuery and replace my RDBMS, my enterprise search engine, and my J2EE application server in one fell swoop by building my applications in top-to-bottom XML.
To be clear, not all of our customers do this. Many are content with the rest of the stack and use MarkLogic to help with XML heavy lifting. But a growing fraction do.
Let's examine some of Daniela's points:
- The problems with the traditional application development stack she highlights on slides 9-12: high cost, inflexibility, and slow time to market.
- The argument for XML on slide 16: spot on.
- (Warning: code on slides 19-26, but keep clicking.)
- Slide 29 is a reasonable argument in favor of XQuery
- The whole permissiveness angle on ACID transactions on slides 32-33 is new to me so I need to think about it more. MarkLogic offers ACID transactions, by the way. But I like the idea (in part because it's good critical thinking) that perhaps the database community is too dogmatic in this regard and that we pay a high price for that dogma.
- Feel free to skip over slide 35 entirely (kidding). I think it mostly summarizes as "XQuery is relatively new" and there is no totally free lunch. Over time the holes will be filled in and MarkLogic fills in several holes already. I don't think XQuery is particularly complicated and I'm certain it's a heck of a lot less complicated than SQL/XQuery Franglais queries that RDBMSs often want you to write to access XML columns. I've seen real deep experts argue for hours over the correct semantics when you're mixing SQL and XQuery. Stay away from that.
- While I'm mostly skipping cloud in this post, I have two comments. First, internally we run some demo systems with MarkLogic installed (quite easily) on Amazon Web Services, so as consumers we like the model. Second, the other day I met with Chris Barbin, CEO of Appirio, and thought he was fascinating guy and Appirio a fascinating company. Among other things they help you, at a strategic level, to figure out which cloud services to use where, and how to link them to each other and to your on-premises infrastructure. In a world where you can rent anything from raw disk blocks to CPU to database to applications to application platforms to BI in the cloud, it surely helps to have a strategy.
- But my favorite slide is back at slide 28 which shows "XQuery's real potential: standalone programming language for information intensive applications [which can let you] build extremely rich applications." I couldn't agree more. And I like the picture even better. It's what we call top-to-bottom XML.
I've embedded the entire presentation below via SlideShare. The original link off the UCI website in PowerPoint format is here.
6 comments:
I am a huge Mark Logic fan, but I don't understand the ML obsession with using XQuery and XML for the entire application. I have designed several apps that use java app servers, traditional java XML tools, and combined them with ML XQuery. They work great, there are plenty of java programmers out there who understand them, not everybody needs to learn XQuery, and they are very modular and flexible. Every MarkLogic developer or evangelist seems to shun this approach. Just like I avoid writing a whole app in SQL and stored procedures, I also avoid a totally XQuery based solution. Is this just a bid to make the XML database the center of the universe?
XRX is THE style for NOW.
I try to avoid XQuery, I spent time to make a XSD --> DDL + SQL. Result I am pleased to stop this:
Scaffolding
. A lot of crazy, stupid, costly softwares try to convert any to any. With good languages as XForms for applications (it enables to forget JavaScript), XQuery and adequate native XML support. I read what are doing Oracle, DB2, SQLServer, they are cheaters when they claim the magic words native XML support
From 1988 to 1993 I was Bull employee in DB/TP division. We ported (in France) on Unix: Oracle, Informix, sybase, ingres and Oracle on GCOS7. We imagine to interconnect them with 2 level TP support (costly and stupid project named DDA). The result was terrific one of my colleague and me demonstrate with an adequate little query that 1 = 0. This was hidden to sales(wo)men. The project did not stop: co managed Paris/Boston/Phoenix (the war design was great). Worldwide gurus where fond of this vapoware. The product had only a few beta customers.
I decided to leave development and moved to support.
My ambition is now: not to develop but to make support and services.
Which vendor XQuery implementation would be used on the cloud?
First, I think XQuery is for querying and returning XML *as-is* or with very simple transformations, to get my bias out.
Next, if Xquery is to be the webapp glue, it needs to be standardized *WITH THAT IN MIND* -- it is not! You pick your vendor and you are stuck. I know there are efforts to bring this about, but I haven't seen any ML people get involved.
-Rob
Dave - I like the intent here. But what's really needed is a set of good examples on how to build these kinds of apps.
For example, I think the Admin app in MarkLogic 4.1 should be a showcase on how to build a webapp using only XQuery code. But I spent some time going through that codebase, and there are a number of things I really don't like about it - very large files, all the files in one folder, lots and lots of duplication (especially the first several lines of HTML on a page, as well as validation errors and many others things), and perhaps the worst - the admin-forms.xqy file, which reinvents a lot of things I get for free with a good Java MVC framework.
Really, the Admin app looks like a maintenance nightmare for a team not familiar with the code. It reminds me a bit of those Model-1 apps we were building in ASP or JSP from 1998 to 2000.
I can buy into the concept that using XQuery code to move data directly from the database to the UI isn't nearly as bad as doing that with SQL and an RDBMS, as XQuery is much more powerful and the code can be much better designed and organized. But I need to see good examples of that to really buy into this approach.
And even then, I think a hybrid approach is the best solution right now. There are too many good frameworks that a JEE server supports to discard the server - an easy example is Sitemesh, which can be used to decorate content generated by ML and avoid duplicating the HTML layout code (or duplicating calls to functions to render that stuff).
But bottom line - MarkLogic needs to show examples of how this can be done well. I think the Admin app would be an ideal way to do this. Maybe 4.2 can show this?
Paul - I tend to agree with your point, which I take to be "I'm quite happy *and* productive with Java + XQuery, so why change." Companies are going to be happiest and most productive with the technologies and skills they have in house. OTOH, what if you were more productive *and* more happy building your entire app in XQuery? This is clearly the case for some folks using MarkLogic (myself included). So, I don't think it has to be one way or the other. Personally, I find it fascinating, both in an academic sense as well as in a practical/hands-on/measurable sense that a single language can do so much, so tersely, and so quickly.
I agree. XQuery as a full blown orchestration language, for the cloud/soa, is great.
When I worked at Fitch Ratings we did just this.
You can read a paper I co-authored with my boss at Fitch about just this.
http://www.xml.com/pub/a/2007/09/12/extended-xquery-for-soa.html
I'm currently working at a well known investment bank doing yet more XQuery for big time transforms plus bespoke validation. I've got over 13 years Java, but XQuery is simply a better fit for certain domains. We certainly envisage a greater role for XQuery in the dev stack, from simple XPath2 queries against the database/forest, to complete XQuery workflows against the same.
Post a Comment