Building service capabilities that are strategic for your enterprise is a key aspect of SOA and lays the foundation for agile business processes in your organization. Many teams are engaged in building service capabilities both as part of SOA initiatives and bottom-up ones motivated by technology teams pursuing the benefits of service orientation.
How do you ensure that the service capabilities are in line with business objectives?
Are there assumptions that hurt your SOA? I believe so! Here are 10 design assumptions that you need to watch out for:
- Service capabilities are always Web Services
- Services need to support only one data format i.e. SOAP
- Services are implemented first and then contracts are extracted (aka code-first approach)
- Service contracts don't have to be reviewed or governed
- Service capabilities from vendor solutions can be consumed out of the box without mediation
- Services handle exceptions in an ad-hoc manner
- Services implement consumer specific logic
- Service interfaces are always non-validating
- Service capabilities are always accessed in a on-demand fashion. No need to support event driven interactions.
- Service consumers will all migrate to new versions simultaneously. No need to support multiple versions.
Please add to this list any additional assumptions that inhibit the effectiveness of SOA efforts!
Great articles, Vijay. Keep them coming.
Could you elaborate a bit on point 9 ? How do event driven interactions fit into SOA ? How would a service know the difference between an event and an invocation if it is stateless ?
Thanks Kalyan! Point number 9's intent is to convey that not all service capabilities might be accessed in a synchronous request/response manner. Some services might be invoked due to business events. These events could be generated from business processes executing in a BPM engine, batch processes, or custom/packaged applications etc. They could also be generated based on business rules that get executed and trigger actions as an outcome. Eventing and SOA is a vast - in fact, there is a book on it.
The core service logic might never know whether it was accessed as a on-demand web service (e.g. SOAP over HTTP) or via event driven fashion (e.g. SOAP over JMS). Your SOA solution should enable you to take the core service capability and bind it to multiple transports.