What could be the problem with logging in SOA in the presence of such wonderful tools like log4j, Java's logging library and similar? Why might we need something special for SOA and why aren't existing techniques enough? The answer is simple and complex simultaneously - in SOA we are dealing with distributed and composed entities that cause problems in log maintenance, not in log creation.

Local Build, Distributed Analysis
Let's follow a typical service development process and see what might go wrong with logging along the way. Assume we have three business services - F1, F2, and F3 - each implementing one business feature. Each service comprises two components built independently by different people and at different times.

Each component developer used log4j to log information and exception notes of different severity. Since the components weren't built for the same task, each component has its own log file. Due to the reuse of components, we can't modify them but can reconfigure each log4j, for example, to create log files in the same location for the same service, at least. We may not merge files online because each component may have its own policy for the log file management, which might conflict with the management rules from another component. Thus, we have six log files in, potentially, three different locations, distributed or co-located: F1C1, F1C2, F2C3, F2C4, F3C5, and F3C6.

Now, it appears that the business defines two business functions where two out of three features may be reused. Being in SOA, we develop two new business services - B1 and B2 - as follows: B1={F1, F2, F3}, B2={F1, F3}. It's obvious now that for a relatively simple SOA case of two business services, we have to deal with 12 different log files, where four of them might be shared by independent services B1 and B2. This case is shown in Figure 1. Listen for a moment to what the operation and maintenance teams would have to say to us about such development.

This isn't all. In SOA, each business service is expected to have a service contract that includes a service level agreement, a SLA. For B1, the SLA has to be potentially dependent on the performances of six foreign logging procedures and with the robustness of up to three file systems (or other data stores like databases). Moreover, the B1 provider might not be the owner of F1, F2, and F3 services. This means the service contract between a consumer and B1 service provider may depend on three other service contracts and related SLAs. The B2 service presents a similar picture.