Why isn't RelaxNG Compact Syntax more widely used

Have you ever looked at a non trivial schema definition in RelaxNG Compact Syntax? Its amazingly readable isn't it? (Once you've got used to the + ! ? * characters from DTDs). Now and again I bump into some RelaxNG compact syntax and think its pseudo code; but no its the real syntax specification! (e.g. in the JBI spec).

When you compare how easy it is to read & write to XSDs its not even funny. Yet it seems we're all still using XSDs all over the place. So next time you have to author an XSD by hand, consider giving RelaxNG Compact Syntax a go then use Trang to generate an XSD if you need one.

For IDE vendors; it'd be nice to have a RelaxNG Compact Syntax tab on our editors when we have to change any XSDs so we can view them as RelaxNG CS instead of all those pointy brackets and namespaces :)

XPath based splitter in one line of Java code

This came up in a recent thread & thought I'd mention it here for those not on the list. If you want to implement the Splitter Pattern from the Enterprise Integration Patterns using XPath then you can use the following line of Java code...

from("activemq:my.queue").
 splitter(xpath("/invoice/lineItem")).
 to("file://some/directory");

Pretty neat eh. Use any language you like for the expression such as XQuery, SQL, Groovy, Ruby etc.
It sure beats programming in XML :)

SOA and Newton versus Einstein's universe

I really enjoyed Pat's analogy of SOA being like Einsteins view rather than Newtons view of the universe. Its a great way to think of the difference in approaches.

It seems for highly loaded systems that we are increasingly we're moving away from the XA and transactional approaches to looser definitions of consistency (caching/dirty reads, alternative locking models, compensating transactions rather than commit/rollback). I liked Pats hotel room reservation example as well; its rather like Gregor's coffee shop example for asynchrony and loose coupling when ordering coffee without requiring XA.

Mock JavaMail rocks. Mocking out protocols and services is damn useful

If ever you find yourself needing to test some JavaMail code, I highly recommend Mock JavaMail. It does exactly what it says on the tin & is very useful. Its yet another project from the incredibly prolific Kohsuke - nice job! We're using Mock JavaMail on Camel to test our Mail Integration and its been soo useful.

All APIs to messaging & integration systems and protocols should have some Mock testing library to allow developers to create easy unit tests and to save them having to mock complex services (which you're never sure your mocks are faithful to the underlying systems & protocols).

For JMS we can use ActiveMQ. For Camel and JBI we have Mock Endpoints (which I wish we had years ago, it'd have made developing ServiceMix much easier). For files you can just use your local file system; for databases you can use Derby, HSQLDB or H2. For HTTP/REST you can just embed Jetty.

I guess the missing things are things like XMPP and FTP. Anyone seen any other interesting mock projects for specific protocols, APIs and services? (Yes I know about jMock :)

Groovy and JRuby punch up!

via Kirk...

It was great fun actually! I think the Java platform won the fight.

I wonder why at JavaOne I always seemed to meet folks from Groovy, Grails & JRuby while drunk in the evenings... I was sober most of the day honest! :).

Enterprise Integration Patterns in Java using a DSL via Apache Camel

For those of you who missed me rambling about this at JavaOne I thought I'd introduce Camel to you.

Apache Camel is a powerful rule based routing and mediation engine which provides a POJO based implementation of the Enterprise Integration Patterns using an extremely powerful fluent API (or declarative Java Domain Specific Language) to configure routing and mediation rules.

The Domain Specific Language means that Apache Camel can support type-safe smart completion of routing and mediation rules in your IDE using regular Java code without huge amounts of XML configuration files; though Xml Configuration inside of Spring 2 is also supported.

A good way to get started is to take a look at the Enterprise Integration Patterns catalog and see what the Java code of an example looks like. For example, try the message filter, content based router or splitter.

Apache Camel is heavily influenced by the fluent APIs or Java DSLs used in projects like jMock for testing mock objects and LiFT for testing web applications (both of which are great frameworks BTW), where Camel's primary focus is on the easy creation of routing & mediation rules (and all the Enterprise Integration Patterns) together with testing them.

One of the things I'm most proud of is the Mock endpoint support which makes it very easy to test that your routing and integration rules do what you think they do; rather like with jMock you can create expectations up front (things that at the end of the test you expect to happen) then fire in some messages to some endpoints; then assert that things arrived at the mock endpoints as you expected. This includes adding jMock/LiFT style assertions on things; such as the second message received on a specific mock endpoint has a header called "foo" of value "bar". This can be expressed as

endpointA.message(1).header("foo").isEqualTo("bar")

All with nice Java IDE smart completion. I've really wanted something like Camel for a while; a nice easy way to configure EIP rules without having to resort to reams of XML - plus being able to test things in a distributed message based system easily is very useful.

Incidentally if you're curious of the name, here's why we called it Camel

JavaOne time!

Am about to get on a plane for the trip to San Francisco for JavaOne. Am looking forward to catching up with everyone. If you're there pop by and say hi; I'll be mostly spending my time split between the Iona booth and the Thirsty Bear :)

Am liking FlashBlock

If you're getting bored of those damn flash adverts on some sites, try FlashBlock