META-INF/context.xml The Office: US Edition
Mar 25

Bloody Web Services :)

Tech Add comments

Yup, a project that I am working on is having a bad time with Web services. The core problem is that interop is just not there.

Because of this, if I am a Web services consumer, I am going to:

Always give out a simple API set of stubs in various languages

As a user of a current Web services provider, I just want to have some bloody stubs which wrap their services and make sure all works well. The current stubs are Axis 1.1-ish, and are not working right.

Why not? due to multiRef. .NET Server doesn’t like multiRef too much (for simple types). When you make a call the .NET Server says something like this right?:

Error: Cannot understand multiref at line 3, element foo

Er no. We get back:

SOAP Error

NO INFORMATION. Fun to debug for sure. “Hmm, let me try this… or this… or this..”

So, I have to learn from this experience and if I am ever a consumer:

  • Give decent error messages back to my users
  • Have good documentation on the common problems
  • Have a lot of sample code showing the services working
  • Have an API that users can download which has been TESTED

Shoot, I would much rather be talking to some damn EJBs! :)

Grr…

proxySoap._getProperty(Call.OPERATION_STYLE_PROPERTY): ERROR

5 Responses to “Bloody Web Services :)”

  1. Ian Lim Says:

    Perhaps you can consider a web service wrapper around an EJB?

  2. Dan Diephouse Says:

    Maybe the decision has already been made, but it looks like you are using rpc/encoded services. The basic profile basically says don’t use rpc/encoded if you want any chance of interop. Really thats where 99% of the interop problems come from. Avoid it and you’ll save yourself a lot of trouble.

    And why won’t your MT installation let me post? Its saying that I have “questionable content?”…

  3. Robert Nicholson Says:

    We are using webservices too and I’ve found that limiting the api to basic types is the best approach. We typically just pass everything as strings xml in xml out. and parse it ourself. As soon as you start messing around with complex types you’re going to have problems.

  4. Ravi Says:

    Hi Dion,

    If you are having issues with the .Net side, the easy solution may be to post this article to Scoble’s blog. He will surely get you a solution :-)
    Or better still Don Box !!!
    Granted that is not a technical solution but still a solution worth trying, IMHO.

    HTH,
    Ravi…

  5. Larry Says:

    I’ve had similar problems. When I tried to get SOAP attachments working with a .NET client and Axis web service.

    Would you use something else if you could decide? At least I would try to use something like Hessian or REST. I’m not a fan of SOAP or Axis. I have not seen a good SOAP web service anywhere. The eBay SOAP API is a good example. They’ve built an SDK on top of it so that it would be easier to use. But it’s still very difficult to use.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'

Loading...