Friday, June 01, 2007
Is REST Winning?
Wednesday, May 30, 2007
The other shoe drops - And then there was light.
What a difference a year makes.
Welcome Anne Thomas Manes. Anne is wicked smart - that is a fact.
May 09, 2006: I'm one of the folks responsible for mixing the Kool-Aid. I presented at the W3C Workshop on Web Services (representing Sun). I participated in numerous standardization efforts at W3C, OASIS, WS-I, uddi.org, and JCP. I have a vested interest in making sure that WS-* succeeds.
May 30, 2007: If you're ready for REST I suggest you jump on board right away and get ahead of the curve," she said. "You'll have to train your developers in REST principles. You'll probably want to adopt one of the new frameworks or help build one yourself to help your developers implement RESTful applications. You definitely need to provide guidance to your people. What you want to do is work to the point where REST becomes the default for all your distributed applications."
I certainly disagree with her time lines, but am glad she has seen the light on REST.
I'm very excited about the post WS-* world. It is settled - to my delight, much sooner than I predicted. This only reinforces my feeling that we are at a major strategic inflection point.
Wow.
What's next?
Via Mark Baker who really does deserve a trophy or some such.
Update Fixed date.
XML Code Gen & Service Description Langauge
. . . while my application code may be tolerant to at least some changes, the generated infrastructure code isn’t
+1 for WS-DuckTyping.
I realize that my WADL Gateway Drug logic is therefore fairly twisted given my own experience with the over dependence/brittleness that results from code gen. My idealist side agrees that it isn't necessary. My "I wanna see this happen" side appeals to it because the current state of the WS-EnterpriseProgrammer thinks in a service description language way. I just want to throw them a bone. I'm not sure this is wise or what.
There are some good comments in Stefan's Does REST Need a Service Description Language? post.
My favorite:
peter: I’m very interested in how a “typical” REST development process looks like (if such a thing exists). Up till now I have to stick to WS-* at work. How would a cross project interaction work in the REST world? What does the service provider project team give to the service consumer project team? Just a set of URIs? How do they implement the REST service clients? Manually, using CommonsHTTPClient with an XML Mapping framework of choice? Do I stress the toolsupport too much?
stefan: "Do I stress the toolsupport too much?"
Yes, I think you do — after all, do you hand over a WSDL without any accompanying documentation when you use WS-*? Chances are you provide the other team with some documentation, either inline or separate, that they have to read before using your service. A great way to document your resources is to return HTML when someone does a GET …
CommonsHttpClient is a good choice. Whether or not you need an XML binding framework is orthogonal.
peter: Yes, you’re right. WSDL is not enough as documentation for the service consumers. Usually we provide the complete client api :) Which was not the intention from the beginning. But most colleagues ask for example code in their preferred language and not an interface description. Then we come to the question why we used WSDL in the first place? There is one thing were it really works. I use soapUI a lot for testing. Point it to your SOAP Service, append “?wsdl” and let it generate a sample request.
I think that Mark Baker sums it up concisely:
Cut the cord already! RPC is dead. You’re not in Kansas anymore.
Wednesday, May 16, 2007
WS-LastYear
I can't decide if this thread feels like yesterday or 10 years ago.
We'll have to see what the outcome is of the TeleBriefing, but wouldn't it be nice if the other shoe fell and we could just move on?
The shoes of course have been dropping left and right, but far too many people still haven't noticed and are uneducated with regards to the misery that awaits them.
It is going to take long enough for all the ancillary - it provides enough business value so suck it up and integrate with it WS-* COTS products to wash through the IT ecosystem once we all agree that it is WS-Over.
So can we WS-WrapItUp already?
Sunday, April 08, 2007
Visualize a Ginormous Standard Free Simple World
Visualize legacy WS-*. And ginormous industry encompassing standardization efforts for that matter. Could this be it? Could it be the last gasp of this madness? CORBA, J2EE, WS-*, and onto a path of more simple sanity? One can dream.
I continue to be shocked that even today, 6-7 years into WS-* that people still think it is the next thing. I am befuddled by this.
I have been a consultant, software vendor, and IT dude (customer). I haven't been an analyst. I agree with Bill here:
What has happened with WS-* promotion, and what is happening with SOA is bad for the industry, bad for shareholder value. Customers will come to reject the vendor/analyst/consultant triumvirate if it comes to appear to be nothing more than a racket. In effect, that would be a rejection of the entire market. This helps no-one, least of all customers, dependent as they are on software and related services.
Update Patrick Logan and James Robertson say it better than I do. Especially - James. He captures what I loathe the most about the echo chamber and how it defines what is mainstream. It makes very well paid smart people stop thinking - stop innovating - stop looking for a better way. Instead they pick the safe route - whatever the echo chamber is saying - even though it has the highest chances of failure. I hope I never become this - if you aren't risking something you will never get anywhere. And you will be a part of what I think is the typical customer's biggest problem - the lack of the will to innovate and succeed.
Thursday, February 15, 2007
REST JSR 311
Here are some other links: Marc Hadley example
Steve Loughran begs them to keep it simple
Hopefully the expert group will resist the temptation to trick it out too much & will just keep it simple. I think there are benefits of doing this - will help spread the REST goodness if done correctly. Please oh please have a firm red line between message framing and message body (i.e., don't slow boil REST into insanity by making things "easy").
Good to see that some genuine REST experts are piling onto the expert group. Keep an eye on the big vendors. I'm sure the individuals are fine, but the people behind them who will start asking questions about how to "monetize" it probably are not. That is what got us into the WS-* mess. Standards as a gateway drug to pushing product is the root of all evil.
And we all know that sometimes people join standards committees to subvert them. I'm certainly not saying that this is the case, I'm just saying . . .
I'm crossing my fingers that this will lead to good things.
Friday, January 26, 2007
Perhaps I overestimated?
Is a Gartner Group VP (Nick Gall) a good enough shot across the bow? To many people, Gartner is a fairly credible information source.
Or maybe they are like Burton Group where they have some analysts that love it and some that hate it so in the end it is a wash (no offense Pete)?
I can only hope that this is the card that starts the house of cards falling down.
Via Bill de hOra
Update Saw this over on Simon Phipps. Obviously over the top - too funny though. Gartner certainly won't think this is true. I will have to defer to the Enterprise Architecture: Thought Leader on this topic. BTW that is a pure bold blog name ;).
I think analysts play an important role in the industry. I do think that you have to be a free thinker though and take what they say (and what anyone else says - especially me!) with a grain of salt. And who can honestly argue that transparency is a bad thing?
Sunday, January 14, 2007
SOAP over JMS
The chances of me using this? Zero.
With SonicMQ, however, I have happily used their RESTish HTTP Adapter that just maps destination names into the URL & looks for HTTP Headers for any messaging specifics. Want to check for a message? Check the response queue via a different HTTP GET. Certainly not perfect, but can be useful when working with a technology that does not have a richer client available.
I took a quick scan of this document & remembered a Tim Bray post from last year.
I guess I won’t offer any further commentary on the contents of this document. I can’t help but feel for the H/I/I/M staff who are going to have to do the work, and am reminded of Fritz Lang’s immortal Metropolis, where Maria says: “Nobody cared about the slaves who died laboring to raise the Tower of Babel.”
Not sure if they already are (don't see any of their names listed), but it would be nice if these vendors got involved in AMQP. That seems to have some promise.
Why AMQP? Though many networking protocol needs have been addressed, a large gap exists in common guaranteed-delivery messaging middleware. AMQP fills that gap...
What is AMQP? AMQP enables complete interoperability for messaging middleware, both the networking protocol and the semantics of broker services are defined in AMQP.
AMQP Model The AMQP model explicitly defines the server's semantics because interoperability demands the same semantics for any server implementation.
Wire-level Format To enable technology-neutral interoperability, AMQP defines an efficient wire-level format with modern features.
Friday, December 29, 2006
2007 Predictions
Here goes . . .
- Even the day coders will run screaming from WS-*. The battle is won; we night coders killed it because we didn't want to be controlled by vendor-pires and it is fundamentally flawed technology. Sadly, even though I believe that it is dead, it will take 2 more years before the industry echo chamber comes to terms with it. Software vendors who are heavily invested in WS-* will spend 2007 doing two things: one last gasp at making WS-* happen and quietly writing their Plan B MRDs.
- REST usage will increase in lieu of WS-*, but it won't unseat messaging and other middleware.
- People will settle down a tad about Ajax. It's great and all, but I've been seeing more and more botched impls. Like just about everything, its just a tool not a dogma.
- XML will finally be considered one tool in the tool chest just like every other technology. Development teams will only use XML where it actually adds value and not force it into places where it does not belong.
- The virtualization march will continue.
- Distributed Cache and JavaSpace usage will accelerate as more people grok the power of this architecture style.
- Apache River will breathe new life into Jini/JavaSpaces. Both will see lots of new interest and implementations. 2007 will be a "rebuilding year" (as they say in sports) - 2008 will be the big year for a Jini/JavaSpaces come back. Someone from Sun will formally apologize to all the people maimed by J2EE in 2009 and acknowledge that they should have marketed Jini as a service technology from the beginning (ok just kidding that isn't going to happen).
- The Open Source patent war will begin in earnest.
- Community Source Software will slowly start to take off in industry verticals as more executives grok the possibilities and come to terms with the fact that they are already sharing industry vertical software with their competitors; they just don't have access or any control of the source code. Look for a success or two in 2007 which will set the stage for a pandemic by 2009.
- Even more smart people will start blogs or at least start reading blogs which result in even more transparency and open collaboration between software vendors, customers, and consultants and ultimately better software, more innovation, and less waste.
Friday, December 22, 2006
2007 Predictions Starting
Patrick Logan has one that I'd like to see come true. I'd at least like to see a good hard look at it. I've lived web services, ESB, EDA, and they all have their issues. I'm sure Jini/JavaSpaces has its as well, but perhaps the best of all of them is the right fit (ok REST not web services).
As the industry comes to term with the failure of WS-* we can either start over and reinvent things again or perhaps take a look back at some of the technology that should have been front and center to begin with.
I will post my prediction next week.
Thursday, November 23, 2006
SBA trumps EDA?
I am a fan of EDA - Event Driven Architecture. I posted about it a bit here.
Its nice and all, but it is not without its problems. It certainly has a role to play in any architecture. But the last time I built one, I ran into some problems as detailed in my series linked to above.
Does SBA (Space Based Architecture) simplify things even more? For one thing, it minimizes "legacy" XML which is certainly a good thing. And the location transparency is mind boggling. Makes things like Sonic's shared subscriptions look quaint.
Just when you were happy that web services are finally dead, there is another shift. And if you are still talking about web services, well . . . sorry.
Friday, September 01, 2006
Give it a REST
I get tired of blathering on about WS-*, REST, et. al. but am sure glad Mark still has his mojo. Seriously, where does he get that mojo?
Saturday, July 08, 2006
Web Services Panicscape Over Under
Tell me that this isn't insane and has one iota of a prayer of making our lives integrating better.
This is madness.
One of the things I used to like to do was to set over unders for random things I encountered in my daily life - like I'm some sort of booky or something. My friends/co-workers would then place fake wagers on the over/under.
Sadly, I am going to set the over under for WS-* collapsing at 18 months. Too many software companies, integrators, etc. have too much invested ($$ and emotion) and too much to depreciate before we can get out from under this one.
If you are interested in placing a wager, please comment.
Tuesday, May 16, 2006
SOAP vs. REST Pointless?
I can understand that opinion. I think everyone in IT integration is frustrated that every wave that comes by that promises to give us massive reuse fails.
The good news is that IMHO services are here to stay. At the very least, they will get a fair shake. Especially with success stories like this from Amazon.
Regardless if Steve thinks the arguments are pointless or not, the WS-* standards aren't there yet. And SOAP really doesn't buy you all that much out of the box. Sure maybe if all the higher level standards amount to something it might, but I'm not holding my breath.
I think that dissent is important.
Steve argues as Anne Thomas Manes does that the tools will save us. He even cites XDoclet as an example. Funny that I use that as an example on why tools are not the answer.
Like I said, the good news is that services are here to stay. How about we just go back to the drawing board on some of the things that are broken instead of slogging on with the 60+ specs? I don't see that happening. There are too many vendor-pires too heavily invested at this point.
The only answer is enough simple OSS rebel frameworks and hopefully enlightened vendors that treat POX, REST, and whatever innovative ideas come next as first class citizens. The truth is there is massive premature standardization occurring. We might get there some day, but you can't just beat people into submission. IT Integration isn't the commodity that Steve describes. At least not where I work.
A big complaint I have against drinking the SOAP/WS-* Kool-Aid is I haven't seen any real success stories on following the WS-* approach with heavy integration. There are many around SOA, but strangely the specifics of what is on the wire are often left out. Admittedly I may be missing these - please let me know if you know of any.
In general I think that the concepts of SOA and EDA are what are really important today. If you can break things down at the proper level of granularity and use whatever you want on the wire (try a couple!), you will be fine in the end. People including me in the past do a lot of hand waving about standards, service contracts, tool support and what not which are important - there just not as important as you think - at least today.
Sunday, May 07, 2006
Spitting up the J2EE Hippo - now what about WS-*?
Also, if J2EE is on the ropes today, who is to say that WS-* won't be in a couple of years? Given its trajectory compared to where J2EE was in the beginning, I think it is quite possible that WS-* will die a much quicker death then J2EE.
Update 08-May-06
To clarify, I thought that Anne's research was very thorough in terms of coverage - it was quite useful. I just was disturbed that given the history on things like J2EE she so easily assumed that WS-* will survive and thrive. Perhaps its her job to be hopeful like that and to try to get momentum going in one direction. My focus is solving integration problems today and in the not so distant future. Perhaps our requirements are different.
Update 13-May-06
I found some interesting links to Anne's response:
James Governor
Mark Nottingham - (he used to chair the WS-Addressing WG at W3C)
Dave Johnson
Sunday, April 23, 2006
WS-DeepBreathing
Pretty funny. I'd add a #6, however ...
6. Cut your losses and move on