I just ran across this nice piece on the Amen Break. Its a video (although the audio portion is really the meat of it -- there isn't much going on in the video portion) that discusses the history of the ubiquitous Amen Break. There is even a mention of Mantronix!
(Thanks to Doug for mentioning the bus slewing his computer does and its concomitant special memory module requirements.)
Generically, the response of an electronic circuit when there is a large increase in its input.
More specifically, from the Apple page on PowerMac G5s and Bus Slewing...
To lower power consumption, heat generation, and fan noise, the Power Mac G5 computer incorporates an automatic power management technique called bus slewing. Bus slewing is designed to run at high processor/bus speeds and high voltage when the demand on the processor is high, and to run at low processor/bus speeds and low voltage when the demand on the processor is low.
I've collected a folder of articles on SOA and Web Services, and this post captures those references electronically in one place so I don't have to retain the paper. I sure wish I had a good way to annotate pages I'd seen directly, and have those annotations be durable, searchable, manageable and based on back-up caches of the articles in case they go unavailable. Maybe that is a problem Google will tackle at some point...
- Caucho releases Hessian 1.0 specification: Binary protocol was posted to TheServerSide.com by Vic Cekvenich on 2004-10-26.
- I wrote and released (on 2005-02-21) a binary encoding of XML (rendering SAX events as a binary stream, leveraging the UTF-8 encoding for numbers requiring more than one byte to store). It is called BSAX-J (the -J suffix is there because the reference implementation is in Java).
Representational State Transfer (REST)
Introduced in 2000 by Thomas Fielding's dissertation Architectural Styles and the Design of Network-based Software Architectures.
Here are a few comments on the article Implementing REST Web Services: Best Practices and Guidelines by Hao He, posted to XML.com on 2004-08-11.
- I found these points attractive: Idempotency and having the caller specify the desired representation in the query (via the URI).
- Under "Query String Extensibility", the paper says "If it needs to consume other services, it should pass all ignored parameters along" (Sounds dangerous - what if one of those sets an option on the downstream service call that makes it bypass security checks or return data in a different format?)
- Also, "XML Schema provides a good framework for defining simple types, which can be used for validating query parameters." That is only so if you are doing a POST with an XML payload. If you are doing a GET, then XML has nothing to do with query parameters, since they will be expressed in the URI.
- Under "Obligated Services", it says "Return a receipt immediately upon receiving a request", but then later says "... it must report an error if the service cannot process the request...". To whom would this error be returned? How? The only logical answer is to return that when later polled by the requester, but the wording of the item doesn't make that intent clear.
- Under "An Implementation Architecture", it says "The architecture represented above has a pipe-and-filter style, a classical and robust architectural style used as early as 1944 by the famous physicist, Richard Feynman, to build the first atomic bomb in his computing team." First off, I'm not really sure how to parse that, especially the relation ship between the last phrase "in his computing team" and the rest of the sentence. But, aside from that, I could sure use a reference there. It sounds interesting and I've not heard it before. Possibly the entry "Genius -- Richard Feynman and modern physics, James Gleik, p. 201, Apacus 1993" in the "Further Reading" section is the one...
Bob DuCharme wrote Amazon's Web Services and XSLT, posted to XML.com on 2004-08-04. He calls out the ability to specify a format parameter, in particular where the value of the parameter can be the URL of an XSLT stylesheet to apply to the XML that Amazon.com would normally send in response to the query. Interestingly, the Amazon.com technology puts a copy of the request into its response, and if you pass in extra arguments in your request that are not part of the API, those arguments are still copied into the representation of the request that appears in the response. This can be useful if you want to pass information from your request to your XSLT stylesheet that will be processing the intermediate data from Amazon.com.
An ugly but popular web services convention. See the specification here.
Back on 2001-04-12, I released a critique of XML-RPC in the form of my own answer to the problem space: XPC. XPC has the same overall RPC style as XML-RPC (rather than being document centric, as is the current trend), but accomplishes it with a much cleaner notation.
Another ugly and baroque (some would say baroquen), yet popular web services convention. In a way, it is the EDI of the 21st century. Specifications can be found here.
Georg Bauer wrote an entry titled "XML-RPC vs. REST" on the Python Desktop Server Weblog's page for 2003-07-03. Georg appears to be interested in the Django Python web application framework, which I've looked at very briefly until now, but will probably look at more deeply soon.
- What's New in WSDL 2.0, by Arulazi Dhesiaseelan (posted to XML.com on 2004-05-19).
- Really Simple Web Service Descriptions, by Rich Salz (posted to XML.com on 2003-10-14).