One of the projects I've been given has Team A writing an application (environment is C#/.Net) that requires to make two new web service calls to another application run by Team B (I don't know their technology). A couple of times I've said "How do you specify interfaces here? Do you use WSDLs?" The Team A techie in South Africa seemed to understand what I was talking about but made some remark along the lines the architecture was not amenable to that approach.
Some of the application functionality can be delivered just using Team A's capability (the design calls for a web service to their stuff but I think they've just embedded the new code and are making in-app calls). The Business would like Team A and Team B functions to be delivered together but at the end of last week the Team A Architect announced "We can't build the Team B functions until they have delivered the web services". This would mean we could not deliver Team B functionality until a Release 2.
Now previously I've had Team A (different client) build using the WSDLs supplied by Team B, stubbing out the calls as you would expect. Then Team A screw in the Team B services when they are built.
I suspect that the client (despite putting 'SOA' in my job spec) is immature in this respect. I'm going to escalate this (gently) to the enterprise architects but it would be useful if you can share what you think is the normal every-day way of doing this in the City.
I'm saying 'WSDLs' but I appreciate they relate to SOAP-type calls (ie RPC-like) whereas a following has grown up for REST where I think the corresponding thing is WADL. Both WSDLs and WADLs are XML and therefore maybe to too bureaucratic for some people. The advantage I guess that there are generators that turn these kinds of things into template classes for creating and consuming web services. But I could see that people might just prefer written documents, either structured or free-form.
What do you recommend?
