The SOA Dependency Problem
Software architecture is all about dependencies. In a SOA, services depend on each other (to be precise: on correct implementations of specific interfaces or handlers of specific messages). This is the external view where dependencies can be described in terms of interfaces, endpoints, message providers, and consumers. If you use a SOA Platform or Enterprise Service Bus, there is also an internal view. It is focused on your service’s implementations. A service implementation will consist of many different, interdependent artifacts: WSDL files depending on XML Schema files, BPEL files depending on WSDL files, Message flows depending on other message flows (OSB Proxy Services) depending on XQuery transformations depending on XML Schema files, and so on. And don’t forget “virtual” things like namespaces, JNDI names of message queues or database connections, and other configuration data constituting a logical link to some external resource. If you want to keep your code maintainable, you better know and manage its dependencies. You don’t want orphaned artifacts. You don’t want misconfigurations like a service on a test server calling another service on a production server. You don’t want dependency magnets that make your SOA rigid. But you do want to understand what is going on, and how all the little pieces play together. This is rather hard task, as vendor-provided tool support is limited. But since most of the artifacts are XML based, they are open for inspection by external tools. This way, we can build a artifact dependency graph which can then be analyzed or visualized. This is exactly what I did in my Eclipse extension SOA Artifact Dependency Viewer.
Picture: A small chain that came with my pocket knife