Hiding ICE in client API

in Help Center
We have an API(java,c#,c) to a service that we would ideally want to be completely free in the API definitions of any dependency on ICE or any other object middleware for that matter. We like what ICE has to offer in terms of cross platform/language support and it's performance characteristics over other solutions in this space so we prefer ICE to other object middleware solutions. To achieve what we want we find that we have to essentially define our API twice and then write tedious code to map between slice generated interfaces/object model and our own.
We have a large client base of our API so our concern stems from potentially large impact on clients if we decide to move away from ICE.
I'm wondering what the best practices are in this area. Do people mostly expose ICE in the client API or try to abstract ICE away and if so, what approaches exist to do this? Has this been a concern to anyone or are we just being too paranoid?
Thanks in advance for any suggestions,
Rich
We have a large client base of our API so our concern stems from potentially large impact on clients if we decide to move away from ICE.
I'm wondering what the best practices are in this area. Do people mostly expose ICE in the client API or try to abstract ICE away and if so, what approaches exist to do this? Has this been a concern to anyone or are we just being too paranoid?
Thanks in advance for any suggestions,
Rich
0
Comments
It depends - as usual.
If your organization were to standardize on ICE as application/object communications infrastructure, then not much would be gained by hiding ICE interfaces behind some abstraction layer, at least for internal applications. You could consider the ICE interface definitions themselves as the canonical abstraction / object model for your organization.
However, often there is a "most useful" way of how an application "looks" at external interfaces, and so it may be convenient to hide external APIs (ICE and other) behind an adapter layer. Such a layer can translate between object models, or take care of error logging, or maybe even handle failover scenarios. This adapter layer would be specific to the application.
Karl
Think about testing without communication infrastructure. It is a matter of observation point. You know, "client" word might hide a world
I have always found uncomfortable use the direct implementation of something instead of a clean interface.
Guido