New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mark Little on Jan 03, 2007
WSDL has always been one of the key components on which Web Services have been built. Although WSDL 1.1 never achieved the status of "standard" (it's only ever been a W3C Note, it quickly became a defacto standard. Some argue that this is simply because there is nothing better, whilst others believe WSDL 1.1 is perfect and needs no update. However, work on WSDL 2.0 has been going on for quite some time. WSDL 2.0 differs significantly from its predecessor, with amongst other changes:
But it is true to say that it has added a lot of complexity over 1.1 and backwards compatibility is not something that has been a core requirement for the technical committee.
Although WSDL 2.0 has been around as drafts for a while, it is still not an official standard. That's where the Web Services Description Working Group comes in: their job is to agree on what that standard will look like and they were due to finish on the 31st of December 2006. However, they have recently applied for and received an extension to the 30th of June 2007, so a standard is unlikely before this new date. Apparently this is as a result of feedback and extra work required from the Nov ember implementers event and the Interoperability Dashboard.
How important is this delay to the take-up of WSDL 2.0? Is WSDL 2.0 right for the industry anyway? The WS-Addressing working group has had trouble getting enough implementations within the technical committee to ratify their own proposed work with WSDL 2.0. The community at large seems split over whether or not WSDL 2.0 is a good thing or a bad thing. Many critics cite the complexity of the specifications as a barrier to understanding, using and/or implementing WSDL 2.0; the fact that it introduces yet another data model; the lack of backwards compatibility (which means yet more new tool support is required); and perhaps that WSDL 2.0 may be a solution looking for a problem. However, supporters dispute the complexity argument; that WSDL 2.0 goes beyond "old style" Web Services to support HTTP/REST; that it offers better support for loose coupling; and that it supports improved interoperability
What do you think?
I see a ton of WSDL of various sorts from all walks of life. Folks still using rpc-encoded, mostly the various doc-lits (wrapped and bare), even some fringe rpc-lit, add to that custom bindings for various stacks and custom protocols etc. etc. All tolled 100s of WSDLs. I've only ever seen 1 actual WSDL 2.0 document - from someone at Amazon - can't even remember the service. Natch, it made use of the REST binding.
Often times its difficult to get folks to think of WSDL at all. Clearly that's because the current tool crop makes code-first so much more compelling for a developer - and staying in a vendor's type system/world view is good for the vendor. That's the real issue though its hard to defend WSDL 1.1 but its what we have.
I think that unless and until the major stack vendors start supporting WSDL 2.0, it will be of dubious value. My impression is that you get to re-tool technology on this scale every decade or so and as far as web services is concerned the major pieces are in place. We have what we're going to use.
Jim Murphy
Mindreef, Inc.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
1 comment
Watch Thread Reply