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.
Featured Post
These days, I mostly post my tech musings on Linkedin. https://www.linkedin.com/in/seanmcgrath/
Saturday, May 01, 2004
WS Good Practices
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.
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.
Friday, April 30, 2004
Wednesday, April 28, 2004
A non sequiter
Phil Wainewright says (about my posting on flexible software):
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.
"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.
Tuesday, April 27, 2004
Another good real world Jython article
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.
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.
Custom metadata or custom code
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.
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.
Subscribe to:
Posts (Atom)