Monday, June 11, 2007
Since each component is small, the development time is short. The method for input/output is also pretty standardized (pipes, no output when no errors, etc). This makes gluing the components together with scripts pretty easy.
So, with SOA, we end up with a similar model, and the network takes the place of the shell. Your business logic (that wires together the services) takes the place of the shell scripts.
The processing can be distributed amongst many machines.
Now, when I compare SOA with IDD (interface driven design), it is because I see the same concepts occurring. In interface driven design, components can be contained and hidden behind an interface. If you use a library like EasyMock, you can develop against un-implemented interfaces, cool. Then (at run time), when using a dependency injection framework (like Spring), the consumer of the interface doesn't have to be aware of any details. The implementation could be a POJO, and EJB, webservice, or anything, the consuming code doesn't know, or need to know.
So, maybe if we just develop good clean code using interface driven design, things like enabling webservices don't have to be painful.