WSDL-first development

Jeff Schneider talks about the role of contracts and requirements in a service-oriented world.

I'm working on a project at the moment where we're facing very similar questions.

On the interface secification front, we're doing something what he suggests: where an interface doesn't already exist (i.e. where we need to work in top-down mode), we take the use-cases and UML sequence diagrams as input and identify the interface a service needs to expose.

We then generate a WSDL file. In our case, we use a nice property of WebSphere Integration Developer to speed us up: a WebSphere Process Server interface is a WSDL file so our product-specific tooling generates a globally-usable WSDL file automatically. This neatly gets round the problem of "do we do the WSDL first or the implementation-specific interface first?"

The second question he addresses is a little deeper: how do we deal with the "analysis impedance mismatch" between the "old" world of function-specific use-cases and the "new" world where we need to think in terms of reusable distributed services?

Again, we're doing something similar to his colleague: we have a document that identifies what operations each service must expose if we are to be able to meet the stated requirements. However, we add an extra step. We use WebSphere Business Modeler to allow the business analysts to draw end-to-end flows. For example, a particular business process flow would show how we provision a service all the way from the user logon to a portal to the invocation of the back-end systems.

The analysts use the tool in "basic" mode, where operations and data types are hidden. However, this model is then passed directly to the service composers - who switch to an "advanced" mode - where data types, interfaces and operations and conditions are shown. By analysing the flow, and questioning how to get from one step to the next, requirements on interfaces that wouldn't otherwise be obvious can be deduced. It is the use of this extra tool that allows us to simplify the handover from analysis to design.

Of course, if this was *all* we used the Modeler for then it would probably be overkill. Fortunately, this assistance in identifying interfaces drops out of its normal usage.