Dependency Tracking in an SOA Environment
One thing I have noticed over the last 6-1/2 years or so in the SOA world is a pretty complicated thing, and that is tracking dependencies. Most IT Architects and Business Analysts who get dragged (usually kicking and screaming) into creating SOA architectures really don’t understand the true nature of implementing such large scale systems and the potential impact it will have in their organizations. The true scope is sometimes believed to be a mystical thing, but it doesn’t have to be.
So you’ve developed some web services. Have you modeled each endpoint knowing every single things it touches? Composite services generally mask the actual scope of an application. This means that you go to do your testing and find out that there is some previously unknown fault that occurs. To top it off, you can’t even track where it came from-it’s not a fault that you had programmed in there! Most services in a service oriented architecture are built for specific functionality.
Its component-based nature generally mimics traditional client-server applications with them just more spread out and a LOT more dependencies. It’s frustrating to developers when developing web services, because when they start to unit test their applications they are relying on either stubs for their interfaces or actual real SOAP-based interfaces to applications. Generally, it is the latter. Typically when they are testing, some production environment faults will never be known until those developed services are deployed.
Tracking where that fault might occur can take you a while, unless you specifically know where to look. Most normal people (those that have a life other than computing) involved with web services don’t know every detail nor do they have a reason to do so. After all, isn’t the promise of SOA to remove the implementation details away from the service consumers? Take for an example, organization A relies on a web service provided by organization B. Does organization A know the actual implementation specifics for organization B. Most of the time they don’t.
Organization B may have broken that web service into a major league gateway service, aka Composite Service, that only returns a few known messages. That web service underneath might actually be making thirty different SOAP calls, mashing data and returning a response message to a known or expected format. Typical things to look for include: How many database calls are being made? What networks does that web service and its associated services run on? What sort of security algorithms are being used between the services? What application servers do they actually use? Are any data transforms being implemented before going off to other interfaces? The dependency chain can be huge!
Properly modeling your environment, your services and all the interfaces that they touch is huge when it comes to this problem. It will set you off on the right foot to do further enterprise service management efforts.