Using Jython with Cocoon

Alex Krut demonstrates using Jython to control Cocoon process flow.

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.

REST/SOAP - 85% plays 15% on Amazon

[Via Tim O'Reilly]

"I was recently talking with Jeff Barr, creator of syndic8 and now Amazon's chief web services evangelist. He let drop an interesting tidbit. Amazon has both SOAP and REST interfaces to their web services, and 85% of their usage is of the REST interface. Despite all of the corporate hype over the SOAP stack, this is pretty compelling evidence that developers like the simpler REST approach. (I know there are many more complex applications where SOAP is better, but I've always liked technologies that have low barriers to entry and grassroots adoption, and simple XML over HTTP approach seems to have that winning combination.)"

Very interesting but I would argue that it is not the case that for more complex apps, SOAP is better. Sure, there comes a point where you cannot encode parameters into a URI but I don't see why it follows that these more complex web services need to throw out the huge advantages of having a GETable URI.

Here is a URI that will invoke a webservice MYWS that requires a whole bunch of parameters. The params are stored in MyParams:

<a href="/InvokeWS?ARGSURI=MyParams&ForwardURI=MYWS">click me</a>

InvokeWS is retrieved via GET (in other words, its a hypertext link). It picks up the argument payload from the URI "MyParams" which is then POSTed into MyWS. Voila, a "clickable" full payload webservice.

Multibloggers and rss aggregators

Mike Champion has a blog on java.net. He has/had a blog on xegesis too.
Simon Phipps is here and also here. Looks like we are headed towards an era when individuals have multiple blogs - like credit cards - or airline loyalty cards. This trend will intensify the demand for RSS aggregators to create a single "view" of interesting stuff and interesting people.

Jython at Java One

Yes Simon, I'm very pleased. Very pleased indeed!

Scripting with Jython instead of XML

From Scripting with Jython instead of XML

My bias is that XML is a great tool that is misapplied when it is used as a programming language.

Amen.

RFID's

If these are, what I think they are...yikes!

Taking XML processing out of the dark ages

There is a lot of XML out there. There are also lots of developers who, day in, day out, craft programs in Java SAX, DOM or XSLT. All these technologies are useful but incredibly low level tools.
As well as being low level, the exhibit that classic sign of costly development - low to non-existent re-use of processing components.
What if you took a platform like the Java Virtual Machine on which you can run a variety of languages, each suitable for certain types of XML processing task. Java itself of course but also XSLT and Jython.
What if you had a way (using XML of course) of parcelling up a program into a reusable XML processing component?
What if you had a studio that allowed you to grab existing components and chain them together - regardless of their implementation langauge - into an XML processing pipeline?
What if you had a scaleable, J2EE based engine for execting these pipelines?
That's what PropelX is.
The ideas underlying PropelX have been developing in my head for well over a decade at this stage. Back to waaay before XML existed and I did my markup work with SGML. The hope is that the ideas inherent in PropelX catch on, the XPipe project for example, is an open source project aimed at creating open source implementations. Propylon will be donating some code to this effort.
An analogy : Not too far fetched. Think of an XML document as a number. Currently, we do all our calculations by hand. Its terribly laborious and re-use is non-existent. Then the concept of a spreadsheet comes along. Bing! All of a sudden, number processing changes utterly and for the better.
The same thing will happen with XML processing. It has to. PropelX, I believe, is headed in the right direction.

PropelX 2.02 now available

PropelX 2.02 now available for download. Propylon's implementation of the XPipe approach to XML transformation. J2EE based. Use XSLT, Java, Jython to build XML processing components or re-use those supplied in the library. I'll be writing some pieces about PropelX here in the weeks ahead.

The next big thing: asynchronicity

The word - asynchronicity - is the best one word description of the future of integration technology that I can think of. Repeat after me:

RPC = sync over async.
RPC = sync over async.
RPC = sync over async.

Now you are in the right frame of mind to approach Web Services. As Ceperez says, The Hive Mind is asynchronous.

The Grinder

Quite apart from its raison detre as a stellar load testing framework for Java, the Grinder is an excellent example of Jython in action. The script gallery is an excellent source of Jython techniques, even for use outside grinder.