Skip to main content

Are Web Services the New CORBA?

Posted by cayhorstmann on July 8, 2009 at 8:56 AM PDT

I am updating the “External Services” chapter in href="">Core JSF. There is lots of new and interesting
stuff: How to use JPA, stateless session beans, and WebBeans. I ditched the
LDAP sections (for which I had received very few queries, even though the
examples are notoriously hard to set up). I reimplemented the authentication
example with a JDBC realm, which was href="">no
fun. Now I am at the web services section.

In the previous edition, I used the Amazon e-commerce service that lets you
browse the Amazon catalog. It is pretty simple, really. Inject the service into
a managed bean:

private AWSECommerceService service;

Then call the service API.

Generate the client-side artifacts:

wsimport -p cvf aws.jar com/corejsf/amazon/*

Put the JAR file into WEB-INF/lib. Deploy, and it just

Except that Amazon has repositioned the API as a “product advertising
API”, and you now need to be an “Amazon associate” to use it,
which makes it less suitable for a book example.

Now what? I found a couple of web services directories href="">here and href="">here. SOAP services seemed pretty
pathetic. Mostly vendor and academic demos. A href="">magic square finder?


There were two useful services that seemed to have a chance of being
long-lived. The NOAA weather
and Microsoft Bing.
Ok, let's make those client-side artifacts:

wsimport -p com.corejsf.noaa

[ERROR] rpc/encoded wsdls are not supported in JAXWS 2.0.
  line 405 of

[ERROR] A class/interface with the same name "" is already in use. Use a class customization to resolve this conflict.
  line 1 of

[ERROR] (Relevant to above error) another "SearchRequest" is generated from here.
  line 1 of
(followed by seven more errors)

WT-*? Aren't these supposed to be interoperable?


Am I beating a dead dog here? href="">This article describes research
on finding web services. In 2008, they found a few thousand services, most of
which didn't seem to work. Are WS-* services the new CORBA? I know there are
lots of interesting RESTful services out there. The only drawback for me is (1)
the data comes back as some ad-hoc XML, RSS, or JSON, and I have to deserialize
it by hand and (2) there is no connection to JSF.

If you can point me to an interesting WS-* service that is free to use,
likely to stay around for a few years, and has a WSDL that
wsimport can process, I would very much appreciate if you leave a
comment. Or, talk me into dropping the web service section altogether.


AFAIK, the IETF is kind of opposed to SOAP... (at least off the record, perhaps on the record)... that might have something to do with the demise of the whole WS-* stack... The other issue is that you really need to ensure you are using the 2.1 version of the WS apis from sun

I posted the standard jax-ws customization for bing's wsdl in :

There is a conflict in the generated artifact names for the bing wsdl. Standard way is to pass a JAXB customization using -B switch to resolve the conflicts. There is also an unsupported switch that should allow you to resolve the conflicts. The following works for bing wsdl. % ~/jdk1.6.0_14/bin/wsimport -B-XautoNameResolution rpc/enc WSDLs are not supported by JAX-WS. WS-I BasicProfile doesn't support them either. There may be some old rpc/enc based services, but they should move to doc/lit

There are two things in your blog that I am concerned about: First of all, if you can't find it, it does not necessarily mean that it does not exist (or is not being used in our case). As you were not able to find a suitable freely accessible SOAP web service sample for your book, you simply concluded that SOAP services are dead. Well, frankly, I miss some logic behind such conclusion. In my opinion SOAP services are these days mostly used within enterprises or as B2B interfaces. These are typically neither free nor public. Could that be the reason why it is harder to find a public and freely accessible SOAP based WS? Btw. for most simple and public web services, where the service is really just about exposing some resources and not about messaging, REST is a more natural and convenient choice anyway, so why would anyone expose such service as SOAP? And secondly, you confuse web services (WS) with WS-*, which is a set of standardized specification to enable advanced features on SOAP based services, such as message level security, reliability or transactions in an interoperable way. These are enabled via so-called WS-Policy expressions attached to standard WSDL elements. Neither of your WSDLs (Amazon, NOAA Weather, Bing) contain such expressions, so those services are not WS-* enabled, so to say. Also, are you sure that those WSDLs are compliant with WS-I Basic Profile? In case you are not familiar with WS-I BP, it is a profile specification which if followed, should guarantee interoperability among different WS stacks? If not, why do you expect them to be interoperable? SOAP web services are not a cure for everything and certainly not a suitable technology for all situations. No doubt, there's a potential for an improvement in all existing SOAP WS stacks to make the SOAP based services development a smoother process. Yet this technology has its place in the IT world where it does a great job. And you should probably get some deeper insight before making such strong public statements.

Yes drop it entirely. WS-* went the way of EJB 2. The SOAP vs REST debate has been and gone. Some highlights I bookmarked:

You'd be hard pressed to make CORBA as slow as web services ... CORBA is an efficient and mature technology and there are great open source implementations (JacORB, TAO, IIOP.NET) and they are all interoperable. see:

Taylor: Those services are all very nice. And none of them uses WS-*. BTW, I found this Netbeans tutorial: It uses a spell checker web service from a company that sells web service hosting, and apparently the price to pay was an infomercial for that company in the tutorial. That service is no longer supported, but they now have a rather amusing "profanity remover":

I can identify with your sentiments, as do perhaps many others. I think the interop story between Glassfish and MS is good, but probably too little too late for the masses. Although REST is essentially arbitrary XML, Atom is not, and as the protocol layer for Gdata, has some potential. AtomPub adds commonality on how collections are grouped, paged, and updated. Btw, has some very well crafted webservice api's of various flavors and does not require special authorization. see Taylor

Nope, that stock quote service isn't compatible with JAX-WS either. It may well be that wsimport is the culprit here, but the point of the section was how easy it is to inject a JAX-WS port into a JSF managed bean. wsimport -p parsing WSDL... [WARNING] src-resolve.4.2: Error resolving component 's:schema'. It was detected that 's:schema' is in namespace '', but components from this namespace are not referenceable from schema document ''. If this is the incorrect namespace, perhaps the prefix of 's:schema' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to ''. line 68 of [ERROR] undefined element declaration 's:schema' line 68 of [ERROR] undefined element declaration 's:schema' line 81 of (The workaround at didn't work for me either.)

@kromagg: Thanks for the tip. I tried processing the WSDL, but it didn't work. Sigh... wsimport -p com.corejsf.ebi parsing WSDL... [WARNING] src-resolve: Cannot resolve the name 'soapenc:Array' to a(n) 'type definition' component. line 10 of [ERROR] undefined simple or complex type 'soapenc:Array' line 10 of [ERROR] undefined attribute 'soapenc:arrayType' line 11 of

They're generally not very interoperable. Personally I think the heavy focus of the major vendors (Microsoft, Sun, IBM) on automatically generated XML bindings has damaged this supposedly XML based standard beyond repair. You can do it *right* too, but it requires a lot more work, and you're forever following some rules of thumb. Don't think I've ever met a developer who can claim they really know what's in WS-I. In any case, web services are quite popular in the bio-informatics world, check out the ones from EBI maybe: Unfortunately it's a little domain-specific, the dbfetch service might be good for pulling down some gene sequences.

If the book is just about the client technologies (and not in deep about ws-*) I recommend you to include a toy example .. I know it is boring to read a book based on too simplistic demos, but in your case and tricks to consume the service seems more relevant than the service itself. And Metro technologies make it so easy to expose a bean as SOAP web-service that I think a page or two showing how to do that may be enough. Just add a downloadable demo to your book and it will be useful in a long term.. IMO: the most complicated features involving WS-* + JSF are: - HTTPS - security is always a mess from the client-side perspective, specially if you are using tokens and not basic auth.. - Binary data, large volume of data being transferred between the service and the client.. timeouts, etc - Exception handling in the client side.

Carol: I too can continue to demonstrate the Amazon service, but for you to replicate it, you have to become an Amazon associate. It's just not something that I want to require a reader of our book to do.

at JavaOne Harold Carr demonstrated connecting to Amazon's web services with a JAX-WS client

ops, the right URLs should have a ?wsdl at the end: business: admin:

if you just want to try, my pet project contracts: business: admin: and then you can check the result in the reference implementation JSF client: * This contracts are alive for more than a year now.. and I plan to invest a few more bytes on it .. but, yes, my pet project will probably disappear in a few years range.... * I agree with you that WS-* is kind of being decomissioned in the market...perhaps because the big hypes are going in the opposite direction.. SUN and MS seems to be the only big companies interested in to develop WS-*... google, yahoo and any other browser-centric company is just ignoring the SOAP as a serious option.. and I tought that in few years we can see the RESTful generation to regret or to review their current bliefs, because REST impose other problems that are nor solved neither discussed nowadays.. let's wait the hype to dissipate and check again in onw or two years..... :)

When I first saw Web services I was working on an internal CORBA app. I was surprised at how similar things were. Web services was a good first few steps but, like most IT problems you have to go through a few solutions before you find the right fit. I think REST feels like the right solution evolved by the people who have felt the pain of web services. It is natural to HTTP and like mentioned already it is easy to either use a parsing library or provide a client library to the user. Heck why not provide the spec and let them choice even better I say.

David, I can easily do that, and it isn't rocket science to parse a simple XML or JSON file. But there is nothing JSF-specific about that, so I am not sure it has a place in the book. I'll consider your post as a vote for the "dead dog".

Cay, I think you hit the nail on the head with "Are WS-* services the new CORBA?" Web Services is trying to solve a problem harder than CORBA took on, with better tools, for similar results. Web services works OK for when you control and can change both ends of the wire. That's most of where you'll see it used, the same as CORBA. Designing a protocol for anything but very specific uses is very hard. And, just like CORBA, putting WS-* in the core libraries hasn't paid off. Few people need them. WS-* is a growing standard. The people who do want to use them may be using a different version than the one supported by the standard libraries, so they have to bring in their own .jar files anyway. Same as with CORBA. Most of your readers will be able to get to the internet. Can you pick a restful service, put a parser in a .jar for your readers to download, and make the section of the book just reference that API in a JSF example without showing the details in the parser? Maybe one of them already has a Java parser for you.