Reusable Services and Granularity

The main point of SOA is reusability of components and services. Implement a service once, and then use it by other services or components. One of the standard examples is a service for checking a credit card. Such a service is indeed simple to define, the interface is straightforward and always uses the same set of arguments, e.g. the holder's name, the number, date of expiry and the amount. A good example to sell SOA.

But in reality, for more complex services, reusabilty is easier said than done, even with state of the art platforms like SecureMiddleware.
I wanted to implement a SecureMiddleware component representing a GPS receiver. This component is to be used by several other services and applications, e.g. a navigation system or prototypes of emergency management systems.
OK, no problem, I thought, a GPS receiver has a quite simple interface, and I just have to map the GPS interface to the component interface, to be used by the other components.
First of all, I needed to develop and test the component business logic, the interface code to obtain information from my good, old Garmin. So I ended up with an interface providing the satellite positions, signal strength, and a lot of error codes. This interface was very complete and provides everything you ever want to know from a GPS receiver in form of a few operations sending around a lot of data. Fine, worked!
Then I wanted to use the GPS receiver for my applications. The existing, coarse grained interface and its operations provided much more data than I needed in my application. So I splitted up the interface into several calls to just get specific information with a single call, e.g. the position. This fine grained interface worked, but was very inefficient, because of the overhead and latency of the multiple calls. Not good either!
So I implemented an additional interface which exactly matches the requirements of my navigation application. Great, now it is efficient, I get exactly what I need in a single call. I do not wast bandwidth with the transfer of unnecessary large chunks of data and avoid the overhead of multiple calls. But if I change the data required by the application, I also have to adapt my GPS service component, which makes the application quite brittle.
If I want to reuse the component by other applications, I have to add additional interfaces. For example when I wanted to transfer the GPS position over a wireless link based on GPRS, I again had to define an interface exactly meeting the requirements of this application. Multiple calls did not work well, due to the high latency of GPRS, sending more data then necessary was forbidden by the cost model of the GPRS services.

So instead of a single component with a single and universal interface I ended up with a single component with multiple interfaces of very different granularity, each exactly tailored for a specific use. I can reuse this single component from all my current applications or other components. But I doubt this approach of multiple interfaces is really in line with the concepts of SOA. At least SecureMiddleware's Policy Management Framework allowed a flexible definition of security policies, so I did not need to implement policy enforcement in the component code. This would completely kill reusability.
So while reusability of services sounds very good in theory, it is hard to achieve for non trivial services, esp. if Quality of Service of efficiency plays a role.