How can the SOA guys succeed in coming up with good interface definitions on day one? Hasn't the whole developer community come to realize that it's very expensive, and close to impossible to work that way?

Comments?

Update (some answers):

  • Mårten Gustafson wrote Good service interfaces on take one?

  • David Ing said:

    Well it all depends on what you mean by 'interface definition'. Services have (at least) three inflection points:

    (1) The Service end-point. i.e. AcmeInsuranceService::

    (2) The understanding of the URI that defines the message (is it an RPC call, is it a document...), i.e. AcmeInsuranceService::DoWork(msg M).

    (3) The Message format and its interpretation by the recipient. i.e. Schema for 'M'

    You can play with all three of those things to get your preferred level of specificity vs flexibility. One downside to this is, of course, everyone has their own level of comfort. Technical standards and toolkits tend to pick people's choices for them too, which still leaves a fair sized 'semantic gap' between what you meant and what they want.

    In an object design if we said that the interface definition was immutable from day 1 then it would clearly be over-optimistic; life is never that kind. The only kind of versioning strategies you can use in SOA are the ones we have we with other IDL based approaches (say, COM), just a form of containment and interface inheritance.

    So what you do in practice is apply behavioural and structural design patterns to your service design, just as your would your OO domain model. Patterns like Visitor, Strategy, Bridge and Adapter are just as relevant to SOA than to any other complex facade on an object model. You just play with the three 'bits' of the interface you have.

    While a lot of stress has been placed on distinguishing SOA away from OO (Law of Distributed Objects and all that), a lot of the same design techniques are just as relevant.

    The personal 'sweet spot' for me is to follow a 'MEST' style approach, but even then the ends really (really) need to justify the means, and you really need to think that you can justify that paradigm before setting off: The 'impedance mismatch' of the message and the object is not trivial and, despite what the press say, the amount of plumbing you will end up doing will be more than you expect. Confusion often clouds your reasons for a message-exchange pattern when you bring in other architecture factors like scale, intermediaries and throughput.

    The WS standard don't help you with your system design, they just help with the trouble of putting bits on the wire in the least non-standard way you can. There is no silver bullet, designing distributed systems that evolve over time is very hard.

  • Magnus Mårtensson wrote Is SOA Agile - or can it be? and Part II