Featured Post
These days, I mostly post my tech musings on Linkedin. https://www.linkedin.com/in/seanmcgrath/
Saturday, February 07, 2004
Files expand to fill the space available for them - even in space
Glenn Reeves has zapped himself some free space on the Spirit rover's storage system.
Giving AdSense a whirl
I'm playing with Google AdSense at the moment. Lots of ITWorld article fodder here. More news anon.
Thursday, February 05, 2004
Web Services and message-oriented applications
Eric Newcomer:
- "While the RPC-oriented Web services stack is getting built out, and the industry is fighting over proposals for transactions, reliability, and notification[2], Web services are still very useful for basic message-oriented applications, including SOAs built using asynchronous protocols."
I believe that asynchronous protocols are the future of SOAs. Some time soon, it is to be hoped, that the industry will realise that building out the RPC-oriented Web Services stack will never make RPC a sane way to build vast, high-latency, decentralised distributed computing solutions. In English - RPC is just plain wrong for Internet class Web Services. On an Intranet, where you are in control of the end points, you can make it work, given enough time and money but if thats what you want to do, use J2EE or DCOM or CORBA. There is nothing magic about Web Services for RPC other than a whole new layer of headaches.
If you want to look at a cheap, solid, scalable way to do distributed computing, look no further than the combination of HTTP and asynchronous messaging using business level XML documents. The beauty of this, is that it is both Intranet and Internet class at the same time. Work with the web - not against it. Its resources + names for resources + an application protocol (not a transport protocol) that make it work.
Jython in Weblogic Server
- "WebLogic Server Scripting Tool (WLST) is a command-line scripting interface (built with Jython) that you use to interact with and configure WebLogic Server. Using WLST, WebLogic Server administrators and operators can perform administrative tasks and initiate WebLogic Server configuration changes interactively or by using an executable script". [http://dev2dev.com/codelibrary/code/wlst.jsp]
Satya Ghattu of Bea, on the Jython users list (jython-users@lists.sourceforge.net) says:
- "...If every thing goes well, this tool will be a part of weblogic server's upcoming release which is slated for release in December, 2004. If you get a chance please try out the tool, and any comments and
suggestions will be highly appreciated."
Excellent news.
Python versus Lisp
Also via Daily Python:
Yes, to that I would add that people piling onto the XML bandwagon owe Lisp's concept of s-expressions a tip of the hat. I wrote about it in Happy Birthday XML back in 2001.
"Now that lots of people are piling onto the Python bandwagon, it's amusing that many of them don't realize that they are using a language which has many similarities to Lisp."Ted Leung.
Yes, to that I would add that people piling onto the XML bandwagon owe Lisp's concept of s-expressions a tip of the hat. I wrote about it in Happy Birthday XML back in 2001.
Wednesday, February 04, 2004
A pushback from Robert Blum
Robert Blum responds to my ITWorld article concerning parallel processing Bottleknecks in information processing.
The bit of my article I think Mr Blum has missed is "In any software system with a lot of data to process [...]". Lots of data is the key here.
The existence of lots of data to process, more often than not points to what the parallel processing folks refer to as "data domain decomposition". A form of parellelisation that is sometimes referred to as "trivially parallelizable".
Processing tasks that are not amenable to data domain decomposition do, of course, exist and it is true that these do not parallelize without a fight and it is true that algorithms of that nature often need to be rewritten to take advantage of paralleism BUT these problems are just not common in business data processing in my experience.
Intellectually, it is very interesting to think about decomposing,say, an n-degree polynomial calculating algorithm to make it work on a parallel architecture. Me? In my day job, I worry about processing millions of invoices or millions of SOA messages or millions of HTTP request/reponse pairs. All of these problem domains are very very amendable to a domain decomposition approach, without rewrites and without rocket science.
I agree completely with Robert that the urge to reinvent is a key problem in our industry and I agree that componentisation of software is nowhere near where it should be. I disagree however, that componentisation is the reason why manufacturing is easy and software isn't.
Manufacturing decomposes a complex assembly "algorithm" into a sequence of simple asssembly algorithms and then uses the fact that the route of end-product N through the assembly line is completely unrelated to the route of end-product N+1. The result? You get simple machines performing small tasks well and you stack 'em as high as you need to, to get your throughput down to what your business needs. That sort of mindset is just what s/w engineering in business needs IMHO. The key metric is not seconds per invoice, it is invoices per second. The two are very, very different. I wrote about this topic, also, in ITWorld, earlier this year von Neumann's curse.
Thanks for the feedback Robert.
The bit of my article I think Mr Blum has missed is "In any software system with a lot of data to process [...]". Lots of data is the key here.
The existence of lots of data to process, more often than not points to what the parallel processing folks refer to as "data domain decomposition". A form of parellelisation that is sometimes referred to as "trivially parallelizable".
Processing tasks that are not amenable to data domain decomposition do, of course, exist and it is true that these do not parallelize without a fight and it is true that algorithms of that nature often need to be rewritten to take advantage of paralleism BUT these problems are just not common in business data processing in my experience.
Intellectually, it is very interesting to think about decomposing,say, an n-degree polynomial calculating algorithm to make it work on a parallel architecture. Me? In my day job, I worry about processing millions of invoices or millions of SOA messages or millions of HTTP request/reponse pairs. All of these problem domains are very very amendable to a domain decomposition approach, without rewrites and without rocket science.
I agree completely with Robert that the urge to reinvent is a key problem in our industry and I agree that componentisation of software is nowhere near where it should be. I disagree however, that componentisation is the reason why manufacturing is easy and software isn't.
Manufacturing decomposes a complex assembly "algorithm" into a sequence of simple asssembly algorithms and then uses the fact that the route of end-product N through the assembly line is completely unrelated to the route of end-product N+1. The result? You get simple machines performing small tasks well and you stack 'em as high as you need to, to get your throughput down to what your business needs. That sort of mindset is just what s/w engineering in business needs IMHO. The key metric is not seconds per invoice, it is invoices per second. The two are very, very different. I wrote about this topic, also, in ITWorld, earlier this year von Neumann's curse.
Thanks for the feedback Robert.
Tuesday, February 03, 2004
From the 'can this be true?' department
Whats the last thing to go through a birds mind when it hits a plate glass window? Probably its tailfeathers. Seriously though. 1 billion birds? That's carinaticide isn't it?
What can cost accounting tell us about software architecture?
Lots in my opinion. Especially if you approach it from a Theory of Constraints perspective. Bottleknecks in information processing is an ITWorld article on the subject.
Sunday, February 01, 2004
Dilbert - so true it hurts
Dilbert often brilliantly reflects harsh tech. realiities but never better than this painfully true observation on user behavior.
Subscribe to:
Posts (Atom)