I just came back from the annual SpringOne Americas conference. As usual it was a privilege to meet and interact with colleagues, clients, and so many other attendees from the Spring community. This year I also had the pleasure of meeting Pete Higgins and Kris Zyp both from SitePen. Pete is the Dojo Toolkit lead and Kris who is also a Dojo developer has a ton of knowledge around using JSON for SOA interactions. He maintains the site http://www.json.com/.
Archive for the ‘Spring Framework’ Category
SpringOne Americas 2008
Saturday, December 6th, 2008@MVC – The Not So Obvious
Tuesday, October 14th, 2008It’s been almost a year since the new Spring MVC annotation-based programming model (a.k.a. @MVC) became final with Spring 2.5. A few months ago I put together an article summarizing its benefits. In my experience the flexibility of @MVC is easy to see by all who get to spend a little time with it. As an internal measure of acceptance among Spring Framework developers consider the fact that the traditional MVC controller hierarchy is going to be deprecated in Spring 3.0 (along with the JUnit 3.8 Spring test class hierarchy).
While there are no “bad” ways to use @MVC what has not yet emerged widely is a discussion on the more subtle nuances and “preferred” ways of using the annotations. For example consider this article, which puts together what the author feels are “best-of-breed” technologies in their particular niches: jQuery, Spring MVC, and XStream/Jettison. I am in no way picking on the author of the article. In fact I don’t even assume he isn’t aware of the points I’m about to make on how to improve the CarSelectorController.java with regards to the @MVC programming model.
For example the .html extension in the @RequestMapping URI can be dropped since it is ignored by the URI pattern match. In fact the entire URI paths can be dropped if the controller is used in conjunction with the ControllerClassNameHandlerMapping. I’d also lose the ModelAndView return value in favor of the simpler Model input parameter. Both methods would return void. With a few more changes like that it’s amazing how slim the methods will become.
As I already pointed out, the purpose of this post is not to pick on the above article. In fact Spring’s own PetClinic shows code that is very similar. This is understandable since the purpose of the PetClinic sample is to introduce new capabilities in the context of an existing body of knowledge.
With the upcoming deprecation of the traditional MVC controller hierarchy perhaps it is time to put the spotlight on more “opinionated” @MVC examples. The swf-booking-mvc sample aims to do that but its points about the @MVC model have not yet been widely perceived. This is part of my reasons why I plan on giving a talk at SpringOne Americas this December in which I plan to assemble and discuss a set of best practices surrounding the new @MVC programming model. Do you have any favorites you’d like to share?
Spring WS and Java Web Service Standards
Friday, December 7th, 2007I will be giving a talk at The Spring Experience comparing Spring Web Services to Apache Axis2 and CXF and expect the question about Java WS standards to come up. Why doesn’t Spring WS support Java standards? One way to look at this is to understand there are two types of Web Services: code-first and contract-first. Both use the same underlying mechanism (WSDL, SOAP, XML) but conceptually they are far apart. Code-first is really a form of remoting in which XML is merely a wire format. Contract-first on the other hand means much more focus on designing an effective contract independent of the implementation.
Consider standard XML schemas used in various industries such as Health Level 7 (HL7), Univeral Business Language (UBL), or even the Global Justice XML Data Model. These contracts are designed so that disparate business entities who need to exchange data can agree on common type definitions (sometimes that’s easier said than done). This involves a loosely coupled source and destination who need to have a stable contract and be able to evolve independent from each other.
Code-first on the other hand is easier to imagine in situations in which a source and a destination are closely related. For example a .NET client and Java service of the same application are really not that concerned with loose coupling but more with interoperability. What’s confusing is that while this is really a form of remoting it is also considered a Web Service. This terminology is fine but just because WSDL is involved in the exchange don’t expect that same WSDL to be an effective Web Service contract. That is to say one that will remain stable over time.
Going back to the question about Java Web Service standards. The standards are beginning to reflect the importance of the contract-first approach. For example JSR-181 defines annotations to influence the generation of WSDL from a Java endpoint. There is also the Provider interface that allows dealing with a message as a DOM tree. While this is an improvement over previous versions, contract-first remains a secondary topic. This is perhaps reflected in the fact JSR-181 defines the Start with Java development model as required while the Start with WSDL is left as optional.
Lastly to think that Spring Web Services is somehow against Java standards would be incorrect. They’re simply focused on different things. In fact Spring Web Services relies on a number of existing Java standards such as a simple servlet deployment model, JAXP, JAXB, XPath along with many other Java XML API’s and data binding toolkits.
For a good treatment of the Java Web Service standards I highly recommend Mark Hansen’s “SOA Using Java Web Services”. It is a fair, in-depth assessment that will give you a good idea about just how “simple” Web Services are. You can also read about some of his personal travails with the standards online in this blog entry.