Just slightly, the first one records everything, the second records nothing. Google Analytics thinks that both are set up correctly but just isn't recording anything for the second call. Now clearly this is an edge case, and there is very little point to what I've done. But it does highlight one of the problems with services, namely the assumptions that people make on the consumers. I've no idea how Google do the recording, but assuming that a page only has one report to remove duplications, refreshes et al doesn't seem to unreasonable. Until a muppet like myself comes along.
This is part of the reason I'm a big fan of contracts as it can be used to place constraints on the consumer as well as the producer. In this case the constraint would be "only one tracker per page". Consumers are going to use the service in ways, some stupid, that you didn't expect without a way to define functionally what is acceptable its liable to result in support calls or a loss of confidence in the service.
Remember, consumers won't know its them that's wrong.
Only a day later from the folks at Google....
Installing multiple instances of the tracking code on your site is not a supported implementation, as it may result in incorrect reporting. We are not able to guarantee the accuracy of reporting with this kind of implementation.So yup it isn't reentrant. It would be interesting to understand what the paticular implementation problem is. Now I have no clue at all how they've coded it but I do know that
- There is a unique profile ID set before each call
- The page information is only collected once on the successful stats page (no double counting)
- Google thinks that both analytics elements are working when you check
I'm not complaining about the service which is superb, but using this to give an example of how consumers do things you don't want, and currently have no way of stopping other than after the invocation. In effect Google is filtering out the data after the fact meaning that the second call has no real world effect, hence by the SOA RM definition is not considered a capability.
This gives an interesting point, is a capability always a capability or is it only from the perspective of the consumer. In this case a non-reentrant capability only exists for a single call and then ceases to exist. Not sure quite how you'd model that.