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.

Dependencies between services

During a architect panel at TechEd Europe one of the questions centered on dependencies between services: Isn't there a contradiction between promoting loose-coupling and minimal dependencies between services on one hand and collaboration between services on the other hand?

In this respect it is important to separate the business and technical aspects of service orientation. Services should make minimal assumptions in the technical realm, for example about location (may vary from same machine to outsourced on other side of the world over time), communication protocol (HTTP, DCOM, MSMQ/MQSeries, RMI, IIOP), message format (XML, binary XML), and many other aspects that are policy to be determined and optimised by administrators/operators rather than developers.

If IT services (provided by machines) are to mirror business services (provided by people), the dependencies between services will mirror dependencies between people. People must collaborate because they are not able (lack of capability) or allowed (lack of authorisation) to do everything that they are expected to do by themselves. For the same reason services must collaborate to perform the task they are expected to do. If a service would try to do everything, you end up with the monoliths and application silos that we are slowly trying to get rid of!

The Nerd, The Suit and the Fortune Teller

I am currently being entertained by the nerd (Clemens Vasters), the suit (Rafal Lukawiecki) and the fortune teller (Pat Helland) on the last day of TechEd Europe. Fortune teller is reconciling nerd and suit by promoting service orientation as the thing that will bring business and IT together. Services represent aspects of the business, that decouple concerns at the technical level in line with how they have been separated at the business level.

The question that fortune teller has not answered is HOW we will decompose the business into maximally independent aspects? What are the rules of thumb to be used when analysing the business? During this conference there are some (Steve Cook, Pat Helland) who hint to people/business actors, their commitments to each other and conversations to reach these commitments as first-order concepts needed to start understanding (and model) business and the automated services that support the business. This is very much in line with my thinking, which has strongly been influenced by DEMO.

My advise would be to first determining the roles that are played by people in a business (using communication patterns). As a next step you can define a (candidate) service for each of the identified roles. Each service performs activities that are the responsibility of the people in this role but can be delegated to software.