BTW, sorry I’ve been out of the loop for a while. Whatever.
Things I hate…Windows Vista. Just kidding (well, not really). Anyway, I hate Web Services that do little more than allow inefficient remote access to a databases.
As you may know, I’m working on a new contract these days for boring details see my blog on the matter. In any case, I was excited to see the 3rd party vender’s published web services that at first glance offered a nice interface to a complex system. They developed a proxy library that’s easy to use, offered an extensive domain library and supports asynchronous communications. I was stoked and thought that this gig would be a breeze after all.
Then reality set in…no support for batch operations. Okay, I can deal with that. The service API had a 1-for-1 relationship between classes and services, alright, I’m still here. Then I found that no objects in the domain library have references to other objects. If object A has a B logically, A will only expose the ID of B. So let’s say I have an house that must have an owner of type person. A person has an address and a phone number, both required. With the service interface, I’d have to add a phone number through the phone number service and an address through the address service. I would get IDs back from both add operations and would have to use those IDs to add a person to the system. Then I would get the person ID back and use it on the house’s owner ID to add a new house. The system’s class hierarchy is much more complex and to say the least and using the web service started to seem silly.
Whatever happen to “chunky” service interfaces? If I used the web services, I would be replacing OLEDB with Web Services…dirty. The argument from the architect was that the granular service API was needed to help performance.