Mar 18
REST inevitably complex?
icon1 Niklas | icon2 Tags: , , . | icon4 03 18th, 2008| icon3No Comments »

Turned out I had to cancel my trip to QCon London due to a customer engagement. Too bad as the conference seems to have been as good as the previous QCons. Oh well, there will probably be more. For my colleges at the conference, their most discussed topic seems to have been the REST track, something that makes me very happy.

My colleague Johan blogged on the inevitable increase in complexity in technologies as they become established. While I agree that REST will likely also see this type of development, I have some hopes for it not being as bad as for the WS-* cycle. For one, I don’t see the curve that Johan shows as having a constant amplitude but rather having an asymptotic curve.

For example, I think WS-* got some things right where CORBA went wrong (text based protocol, (mis)use an established protocol). This type of curve will never actually reach the golden middle way, but at least we’re getting closer. Will we be hyping some new technology-de-jour beyond REST? Sure.

Also, some (like me) would claim that REST builds on a stronger foundation then CORBA and WS-* do, and therefore will have an easier time growing to fulfill a greater set of requirements. In addition, REST did not come out the enterprisey dungeons of IBM and friends but rather from a pragmatic community and one quite wise man. Hopefully, this community can continue to foster REST and limit the inevitable complexity. For example, I don’t see REST repeating mistakes as worship transport independence (while only embracing HTTP anyways), XML level encryption or distributed transactions.

Jun 5
Quote of the day
icon1 Niklas | icon2 Tags: , . | icon4 06 5th, 2007| icon3No Comments »

Bill de hóra seems to be nailing them these days. 

"SOA seems to encourage business to meddle in IT at the wrong levels and might actually prevent commoditization by making all this stuff specific to a business at-a-point-in-time; like encouraging Service Oriented Electricity instead of electrical Grids and uniform access to outlets."

On the service-oriented-architecture list.

The fact that quotes like this makes me giggle probably says a lot about me having spent to much time thinking and talking on these topics lately.

May 31
Quote of the day
icon1 Niklas | icon2 Tags: , . | icon4 05 31st, 2007| icon3No Comments »

As a follow-up to yesterdays post.

"I’ve set my bozo bit for WS and SOA types who are repositioning themselves as REST stalwarts. Spotting a bandwagons is not an indicator of competence."

Bill de hóra on rest-discuss

May 30
REST going mainstream?
icon1 Niklas | icon2 Tags: . | icon4 05 30th, 2007| icon31 Comment »

Looks like Burton thinks REST will go mainsteam in the next couple of years. Given that we’ve been feed that protocol independence and stuff like WS-MEX, ERPs and WS-Trust was really important, it’s interesting to see the big guys now thinking REST is the next big thing. Did we all of a sudden realize that all that cruft wasn’t all that crucial anyways?

Tool vendors is getting into REST. I guess any support is a nod of approvement, but given the focus on code-first, remote invocation, ignore-the-network frameworks that rules the WS-* world, I keep my hopes low for the near future. Please convince me otherwise, in the meantime a good HTTP client, XOM and  Restlets will be sufficient.

Jan 12
SOAP JMS binding
icon1 Niklas | icon2 Tags: , , . | icon4 01 12th, 2007| icon3No Comments »

Looks like the big guys finally got their act together and wrote both a specification for JMS IRI format and a SOAP JMS binding (via Dan Diephouse). Now, I’m certainly not the right person to judge the quality of the SOAP binding, but I do like the fact that there might actually be one soonish.

On the IRI format, its currently only based on using JNDI for identifying the connection factory and destination. However, with JNDI falling out a fashon the last couple of years and JMS commonly running outside the container, I find this a bit lacking. However, the spec leaves some leeway with the following quote:

JMS relies heavily on JNDI for interoperable functionality (vendor extensions may provide alternate means of acquiring a javax.jms.Destination, but only JNDI is interoperably specified).

That only covers the destination, not the connection factory. I would prefer that the spec more clearly allowed for both JNDI based and a more “freeform” syntax that’s up to providers to define. How about:

jms:jndi://connectionFactoryName/destinationName?params

and (for MQ in this example):

jms:wmq://queueManagerName/queueOrTopicName?params

ActiveMQ and WebSphere MQ already has defined similar URL formats that could be adapted. JMS is inherently not interoperable between different providers anyway, so having these provider specific URLs wouldn’t hurt. And it would allow using them without having a JNDI implementation around.

Jun 25

The XML Query WG has announced what they belive is the completed release of the test suite for XQuery. All in all, it contains a whopping 14500 test cases. That’s what the WG think is necessary to fully test the complete specification, all 239 pages of it. I think it will be a crucial tool for ensuring combability between different XQuery implementations and might make XQuery skip the long period of incompability that most other specifications has to endure. I just wish that the SVG WG would make the same prioritizes, instead of trying to release yet another bloated spec long before the previous is even close to being proven and successful.

And, if 14500 test cases are required for XQuery compability, how many will be needed for WS-*?

Jul 3
SOA is DOA?
icon1 Niklas | icon2 Tags: , . | icon4 07 3rd, 2005| icon3No Comments »

As usual, Sean McGrath says it best. I agree that WS-* has gotten our of hand and it’s time to save the pieces that actually adds something.