« Right Services, Wrong Tools | Main | Open source and product business models »

503 Service Unavailable

Simon Brown enters the hell that is J2EE fineprint:

The reason that we discovered this is because we were trying to figure out the best way to implement logic like, "sorry, not quite ready to process this message yet". - Simon Brown

That would be 503 Service unavailable in HTTP. I love HTTP.

I came across this problem recently in a different context to Simons' transaction case - mine was MDB throwing an exception to the container and the container continously resending the message. The simplest answer seemed to be to have retry/dead-letter queues - otherwise you end up tied into someone's JMS provider via configuration lock-in. Sometimes you don't want to have a message retried after a number of efforts; sometimes it has to run within a certain time; sometimes there's no point in resending (like invalid XML in a text message). Having retry and dead-letter queues is more work, but it is somewhat portable. Sometimes what JMS provides is too low-level to represent the application problem - there's a world of difference between a transaction and an order fulfilment.

And that's why I love HTTP (and Internet protocols in general) over APIs - quite often they have exactly the semantics your application needs.

June 4, 2004 12:34 AM


(June 4, 2004 07:52 PM #)

Sorry - off topic, but the post reminded me. Are any of the FIPA lists worth watching from a SemWeb point of view?

Trackback Pings

TrackBack URL for this entry: