An XML editor with RelaxNG support

Oxygen starts what will (I predict) become a trend - especially in document centric XML (and you know in your heart that all XML should be document centric don't you:-)

Scripting Ant with Jython

Scripting Ant with Jython. And this from James Duncan Davidson Ant dot-Next. Oh, and scons looks interesting too. The Python/Jython world is moving so fast these days its hard to keep up.

Bursting a couple more SOAP bubbles

As Mike says on his java.net blog, there is very little that we disagree about in the XML world. We see eye to eye on way more things than we disagree on. Mike points to some areas where he suggests SOAP can add value over XML/HTTP. I can confirm that this is something we do disagree on.

Mike puts forward 6 areas where SOAP can add value of HTTP/XML. Lets look at each one:

• Routiing and reliable messaging across multi-node networks, such as when one must perform content-based routing from an HTTP gateway to the appropriate back-end service (e.g., the one nearest to the consumer).




• No problem. Put your XML message payloads in a suitable business level envelope and use RESTian URIs to issue receipts for two-phase commit reliable messaging. [Irony alert - the Biztalk Framework from Microsoft has offered this facility using nothing fancier than ASP pages for years now :-)].
  


• End to end encryption (from consuming application to service rather from consuming application to SSL gateway)
  
  
  
  • No problem. I can encrypt XML for end-to-end delivery just fine. I don't need SOAP for encryption.
    
  
  
• integration of legacy services that may not have an HTTP URI
  
  
  
  • No problem. HTTP proxies are wonderful things.a HTTP "stack" is a trivial thing to put together in comparison to a SOAP stack.
    
  
  
• Non-HTTP communications protocols and interfaces such as BEEP, MQ and JMS




• No problem. HTTP is ubiquitous, proven and simple. Need JMS, MQSI etc? Tunnel'em over HTTP. A lot of JMS stuff out there works this way right now. SOAP adds nothing here.




• Multipart service transactions that must be committed or rolled-back/compensated as an entity
  
  
  
  • No problem. I can rollback a transaction by exchanging a message in XML over HTTP just fine. If anything, SOAP is counter-productive here as it encourages a mindset in which the network disappears from the equation. See The Eight Fallacies of Distributed Computing. I have heard developers say that SOAP gives them what they need to do ACID transactions on their intranet. ACID in a distributed system where the network is not under your complete control doesn't work, hasn't worked and won't work. If you really want to give it a go, try CORBA!
    
  
  
• More complex interactions between service suppliers and consumers that need to be described and choreographed.
  
  
  
  • No problem. Description and choreography are orthoganal issues. I can describe business processes and orchestrate them just fine without regard to how the nodes in the process communicate. Again I think this is an area where SOAP is positively counterproductive. When I see developers bludgeoning their business process state machinery into what is basically the envelope structure of a software interrupt I weep :-)
    
  
  

Yes its good that the SOAP WG took the concerns of the TAG on board and added GETability to simple SOAP services but its , well, "tokenism" is one possible word for it.

Fact is, the last thing the budding world of web services needs is a premature standardisation of the wrong paradigm. RPC. Thats where SOAP started and it has been backpedalling like crazy, adding more and more layers of goo, ever since. HTTP is not a transport protocol guys. It is a resource transfer protocol. A very different - and very powerful thing.

This one needs to be ripped up, torn down, rethought and started again - *when* and only *when* there is sufficient body of lore on how web services really will work. We cannot just standardise our way around finding out what really works! Lets do that,then worry about standards when there is something worth standardising.

I would urge anybody interested in this stuff to read Mark Baker and Paul Prescod.

Python's creator welcomes the scripting noises going on in the Java world

From this computerworld article:

The new standard is a good idea, said Guido van Rossum, the creator of the Python scripting language. "Many Python afficionados need to use J2EE to earn their bread, and having the ability of using Python in that environment, for at least some of the tasks, would certainly be welcome," he said in an interview conducted via e-mail.

Now that Sun's J2EE (Java 2 Enterprise Edition) platform has gained widespread acceptance, the company is beginning to focus more on developing the Java language. Adding scripting support is part of this effort, said Shipe. "We did spend a lot of time focusing on the platform," said Shipe. "Now we're turning our focus so that we can beef up the language side of Java."

Excellent. Long overdue but great to see Java the platform separate from Java the language.

Joi has too many gadgets!

Joi Ito charges up for a Finland trip

SOA Mailing List

A Yahoo mailing list for discussing Service Oriented Architectures. See you there.

Why not just use regular expressions to parse XML?

I was asked this question today. By my reckoning, that is the 1,643,674,567,422,673'th time I've been asked. I can think of no better source explaining the issues than Kendall Clarks article on xml.com - XML isn't too hard.