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 Feb 11, 2008
WSDL is a key technology for SOA, and yet creating and editing these files is about as much fun as straightening all the noodles in a bowl of spaghetti with a pair of tweezers.They idea is to extend Relax-NG Compact Syntax by adding support for services, ports, operations and messages. The project aims to encourage developers to think about the WSDL from the start, as part of the service contract and not as an after thought:
The programmer begins with a WSDL file, and as part of the build generates the service interface that is then implemented by one or more classes. The challenge here lies in creating the WSDL!So for instance a relatively simple service could be defined as:
#And Relax-WS would then generate the associated WSDL automatically. But does this really help isolate the developer from WSDL? It it sufficient to silence some of the WSDL critics? As one of the comments on James Strachan's blog states:
# This is "hello world" in relax-ws.
#
service Hello {
port {
operation SayHello {
in {
element name {xsd:string}
}
out {
element message {xsd:string}
}
}
}
}
Definitely cool, but doesn't this suffer from the same shortcomings it claims to fix: "code-driven development........is fast for development, but can easily result in platform-specific features sneaking in, which renders the interface unusable for cross-platform clients."
Don't get me wrong, I despise WSDLs, but I would think auto-generating a WSDL from Java or a relaxng snytax would both result in "unusable cross-platform clients."
That is an approach I've always used, but at some point read an article defining it using that term, and I always thought it was fitting. Code First, Contract Aware, as a mean to generate WSDLs...
Meaning, the developer could make their web service interfaces in code, and have the WSDL autogenerated, but not do so in cowboy style: define specific interfaces/contracts (don't use your internal DTOs straight as return types! never never never!), build those contracts as if they were a UI Model object, return those, and be "aware" of what translates to what, so you get really what you want.
Using, for example, WCF from .NET, building contracts that way, using attributes to fine tune your contract, you can have excellent WSDL generated, very easily. They'll also be fully WS-I compliant, so that shouldn't be much of an issue. You still need to have basic knowledge of WSDL, but you don't have to actually use it!
...and if you'd like to try it out in a real runtime there's now an Apache Tuscany module to support Relax WS interfaces. Read about it in this blog post
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.
2 comments
Watch Thread Reply