Joe Gregorio points out the weirdness of tunnelling HTTP over SOAP. 18 months ago I wrote about the the rise and fall of HTTP.

I sure hope I'm wrong. I see a race condition here. Web services as RESTian SOA platform versus Web tech as new-object-RPC-platform-gosh-angle-brackets-sure-make-all-the-hard-problems-go-away platform.

posted by Sean 2:46 AM

[Link] . . .

Tim Bray nails it - pass messages, use XML, asynch beats synch.

To Tim's fourth point about the need to support a function/method call semantic for application developers who think that way, I believe good old synch-over-asynch is the way to go.

- Build your SOA on a completely asynchronous, XML message passing substrate

- Make all services event driven, long running processes

- Use an outer layer of adapters that support a synchronous views of services. e.g. WSDL's for each service and a SOAP server. On receipt of a synchronous service invocation request, The SOAP server fires off the request message and waits for the return reply message. This reply message is then passed back to the caller.

Works a treat.

posted by Sean 2:29 AM

[Link] . . .

Thanks to Pat for pointing me at this.

posted by Sean 1:28 AM

[Link] . . .

Phil Wainewright says (about my posting on flexible software):

"Thus, he concludes (and in fairness I should point out that I'm still paraphrasing), it's much easier to write software that doesn't provide for user parameterization using metadata, and it means you get slicker software too.

Unfortunately what he doesn't mention is that it is much harder to operate a business using software that users can't configure."

Users can on course configure software with my suggested approach. You simply build GUIs to capture the configuration data from the user and that program - instead of writing, say, an XML file - *writes* a program. This program is then simply imported.

This is a time honoured technique that works gloriously well when you have dynamic (i.e. the ability to eval()) code as part of your deployed application.

I recommend Jon Udell's article Programs that write programs.

posted by Sean 9:28 AM

[Link] . . .

Hats off to IBM for continuing to publish great practical articles about Jython. Here is one for DB2 programmers.
If there was an award tomorrow morning for "most awesome Java productivity tool without a major vendor backing it", Jython would win it hands down.

posted by Sean 8:24 AM

[Link] . . .

Jeff Schneider asks about the pros/cons of paremeterisation (customisation) through metadata or through code.

Customisation through metadata: Big PRO - simple. Big CON: inherently self limiting.

Customisation through code: Big PRO - turing complete (if you do it right). Big PRO: Can do anything your can do with metadata and then a whole lot more. Big CON: turing complete:-)

I had an epiphany once. I needed to parameterise two variables - lets call them foo and bar.

Option 1 - create an XML file (yay!) and read 'em in at run time with a parser and a tree walker and a variable stuffer.

Option 2 - create a Jython file and um, import it .

Option 2, in its entirity:

(Main code)
    from RunTimeArgs import RunTimeArgs

(Configuration code - RunTimeArgs.py)
    import sys,time

    sys.stderr.write ("importing parameters")
    RunTimeArgs = {
        "foo" : 24*7*60,
        "bar" : time.time()
    }

Note all the cool stuff I get for free in the second approach? Nice variable syntax. Full access to other modules. Expression evaluation. etc.

As it happens, this weeks ITWorld, e-Business in the Enterprise article The mysteries of flexible software touches on a related point about customisation.

posted by Sean 1:49 AM

[Link] . . .