• 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java


Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Ruud Steeghs at 19:24 on Tuesday 21 February    Add 'REST or SOAP? Why not both?' site to delicious  Add 'REST or SOAP? Why not both?' site to technorati  Add 'REST or SOAP? Why not both?' site to digg  Add 'REST or SOAP? Why not both?' site to dzone

It’s tremendously difficult to argue a RESTful approach to a service-oriented architecture (SOA), when the corporate mindshare is SOAP–where project stakeholders tout the SOA buzzword, nod their heads sagely when you say SOAP, nod their heads again when you say XML-RPC, and then look blankly when you mention REST. At an official level, it seems that for the IBMs, Suns, Microsofts, and Oracles (et al) of this world, REST isn’t even on the radar; perhaps more because they would find it difficult to build a commercial strategy around something that is based on simplicity and standards (like HTTP) that have been around for years, than from a true lack of visibility at the coalface. So when the push from on high is for SOAP web services and associated technologies, and your business partners and colleagues have been drinking the Sun/MS/IBM/etc. Kool-Aid, you’re generally fighting a losing battle if you’re promoting alternatives. [article]

Posted by Ruud Steeghs at 14:15 on Sunday 22 January    Add 'Tim Shadel says JSF isn’t their choice for the future' site to delicious  Add 'Tim Shadel says JSF isn’t their choice for the future' site to technorati  Add 'Tim Shadel says JSF isn’t their choice for the future' site to digg  Add 'Tim Shadel says JSF isn’t their choice for the future' site to dzone

Tim Shadel, in a podcasted talk linked to from “JSF: The 7-Layer Burrito I Won’t Eat Again,” says that after using JavaServer Faces for months, they’ve decided that they wouldn’t use JSF in the future. The primary reason? JSF uses POST, not GET, and as a result, links to specific aren’t conversational state isn’t preserved, unlike with REST.

In the podcast, he says that the URL hiding affects JSF from start to finish. While he says JSF may be all right for applications that use internal state, it will be awful for applications that should expose content urls to, say, search engines – like blogs or other content applications. Further, the URL hiding affects deployment, because applications can’t refer to other applications’ states.

The JavaServer Faces specification does indicate that POST is used exclusively; the form tag doesn’t define a pass-through attribute for “method” to allow use of GET, and while it may be possible to create a render kit for JSF that enables use of alternate methods, this seems like a strange requirement for application developers. However, a quick search on Google does show a few examples of embedding data in a URL for use in JSF.

Of further interest is the note that this is the “first of a long list of reasons why the JSF 7-layer burrito won’t be on my round for seconds.”

What are your experiences and opinions about this? Is this a critical limitation of JSF? Would this affect your willingness to adopt JSF in public-facing applications? Why or why not?

© 2020 Java Competence Network. All Rights Reserved.