Monday, May 26, 2008

An internal API exposed as SOAP is not a webservice

As the system we build at work grows, more other systems are to be connected to our system. So is the case with a system that handles domain registration and hosting products for our smaller customers.

This system is originally a self-contained system. It's a web-application that has all the work-flow, provisioning and billing build in. And now some architects have decided that it should be connected to our system, so the big commercial systems can all offer these products without having to resort to manual steps performed by human operators.

There was resistance. The product managers and designers didn't like that idea. I assume the builders don't like it either, because the development is out-sourced and that would mean less income for that company. So after some political 'nudging' it was accepted that our system should be able to talk to theirs. And they we're going to give us webservices that enabled our system to offer the same products and functionality as their web interface does.

When I got the documentation on the webservice I was unpleasantly surprised. There are a lot of methods. And they're all small methods. They all have a very, small, singular purpose. As far as I can tell, they took the public properties of their Business Logic Layer and their DataAccess Layer and made those all into SOAP methods and called it a nice webservice interface. It's going to be a challenge to get that working smoothly...

No comments: