EDA Lessons Learned - Scaffolding

See EDA Lessons Learned for the list

Scaffolding is useful all over the place in software. EDA and SOA really can benefit from it.

Scaffolding is especially useful in large new development efforts. Services reach code complete at different times. You are totally hamstrung if you wait until all services are complete to start testing. The scaffolding (i.e., mock services) can be used to simulate the services that are still in development.

Once developed, scaffolding can be useful when a service that is not available. If you don't have scaffolding, development and testing can grind to a halt while you wait for the service to come back up.

Scaffolding certainly doesn't come for free - you have to develop it like any other service & it can be every bit as complex as the real service. Its often worth the investment though. You don't need a scaffolding impl for every service you write. Mock services are particularly helpful for services that wrap a volatile resource or a service that is outside of your control (e.g., different org. that has a different development schedule).

A SOA or EDA that provides good location transparency makes swapping in/out scaffolding easier. For our EDA style system we just disable the real service and enable the mock service. The mock service subscribes to the same JMS Destinations, and produces the same event types. This is great because you don't have to modify anything on the clients to swap in the scaffolding. You can achieve the same thing with UDDI or RSS - I do really like the EDA style though - when you are working in an event cloud you get extreme decoupling which rocks.