Saturday, July 31, 2004

How Service Clients Affect Service Design

Mike Taulty writes about how assumptions about service clients, for example the protocol they will use (HTTP especially), can influence the web service interface:

"I keep getting bogged down in what I’d call a “technology” gap between web services implemented on top of HTTP and web services implemented (potentially) on top of other protocols. I’ve been having a lot of discussions around this lately and I thought I’d blog what I’ve been thinking about as a means of getting my thoughts in order and, thereby, preserving my sanity.

The problem arises for me because HTTP is implicitly a request-response protocol and the technologies that we have for building web services today take “advantage” of that fact to implement their services in a particular way."
The interesting scenario that Mike discusses is where a service is not able to handle a request fast enough to be able to return a response within the timespan of one HTTP connection. How do you return the final response to the original requestor in that case? Mike proposes a service interface design that allows service clients to poll for the final response. I am not sure that is the way to go. To quote from my own comment on his blog:

"If I need to cater for polling clients I would use a similar solution as for polling people. Implement a core service that expects to live in an ideal service world with a WSDL as described in my first comment. Then create a second service that represents the polling client, acts as an adapter for the core service and has a WSDL as you propose. Polling clients would talk to the adapter service, non-polling clients (peer services) would talk directly to the core service without being forced to poll for their information."
See comments on his post for the rest of the discussion.


Post a Comment

<< Home