Saturday, November 24, 2007

Services & Volatility

Quick and dirty isn't what you normally think of wrt architecture, but sometimes it's useful to keep from getting caught in the weeds for too long. In short:
  1. Define your information model
  2. Define your abstract model (the business objects, as I think of it)
  3. Define your services and their bindings to the information model
  4. Define your processes and their bindings to the services - paraphrasing here, as the language is a bit vague.
(from David S. Linthicum's Reference Models and Architectures via James McGovern)

Key point is this: "The core idea here is to place volatility into a single domain, or a place where the use of services (and thus the information) can be defined, and redefined, according to the requirements of the business."

And that's my jumping-off point.

Traditionally this volatility domain has been in application logic (stored procedures, business logic code, and inevitably UI code). My thinking has been moving towards the idea of pushing that volatility domain more to the services. Not the data & transactional services that Linthicum defines as being part of step 3 above. But rather to move the business processes into workflows accessible to the business as services. This would avoid multiple constituencies having to independently wire up the underlying services (data & transactional) and ensure that everyone is using a consistent workflow.

I see challenges with this approach though...

First challenge is that workflows imply that state is being kept because they are asynchronous. You can hand a token to the client that will later let the client pull up the workflow in its current state. But now the client has to store and track that token itself, and handle situations where the state returned from the service isn't what was expected. Maybe I'm expecting too much here, but if you're going to go to the effort of making the workflow consistent across the business, then you really want to do it from end to end.

Maybe a solution would be to use webparts that front the workflow service. Here you would wrap the workflow service in a UI and keep it self contained, leveraging the ability of the webpart to share data with other webparts. And so consumers are stringing together common webparts that they organize in a way that makes sense for their part of the business.

Second challenge is handling the inevitable change that occurs in those workflow services. Maybe you can solve this with versioning for 80% of the consumers, and the rest of the consumers we have to accept have their own specific needs that aren't going to be met by the workflow services and this population of consumers will have to wire up their own specific code against the data & transactional services.

So, webparts (at least in a Microsoft world) fronting workflow services. It's not a bad approach, but those webparts are going to start getting complex... not sure we haven't just traded one problem for another. But still, there just might be something here worth pursuing....

No comments: