Desiging SOAs With Orchestrations
I am pondering about some basic patterns of service oriented architecture design. I am trying to figure out if it's a good pattern to always abstract a service behind an orchestration.
The benefits are:
- Easy integration with other available services for "aspects" of the web service call (dynamic lookup, message routing, logging, error handling, notification, etc. )
- Abstraction of the service interface, that you may not own behind an interface you own.
- Consistent design pattern
The major drawback is:
- The overhead ( > 2x ) associated with another SOAP service call and some additional overhead for the orchestration engine. In the OO and the component world, it was pretty inexpensive to abstract a 3rd party class components behind your own interface. With the current generation of Web service plattforms service calls carry a lot more overhead, even when they are local. Indigo will eventually fix this problem, but it's still quite some time before we get our hands on it.
Now, if you own the web service interface then the second advantage bullet is less important and aspects may not be important to you. In those cases it seems to make sense to skip the orchestration unless you assign a high value to having a consistent design pattern. You have to weigh if you need down-to-the-metal performace (then why are you doing web services?), or if scalability is really what you are after. That's where the role of the service architect comes in, to help you make those trade-off decisions.
I'd love to hear other opinions. What are other criteria do you look at when you make those trade-offs?