Hiding ICE in client API

rich

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

kwaclaw

rich wrote: »

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

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

marc

Of course you can hide Ice behind an additional API layer. However, just because it's hidden, doesn't mean that it's replaceable in case you wanted to move away from Ice. In order to be able to replace Ice, you would have to find another middleware that has equivalent functionality, or extend another middleware so that it provides such functionality. Provided that you don't only use the most basic functions of Ice, this is not practical or even impossible. For example, I think you would have a hard time replacing IceGrid, regardless of how well it is hidden.

ganzuoni

rich wrote: »

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.

Yes, though tedious, in the end is the fastest approach.

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.

Other factor could be considered too.
Think about testing without communication infrastructure.

I'm wondering what the best practices are in this area. Do people mostly expose ICE in the client API

It is a matter of observation point. You know, "client" word might hide a world

or try to abstract ICE away

No, see Marc reply. Stay at business level.

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

As someone else already replied, better than me, it depends.
I have always found uncomfortable use the direct implementation of something instead of a clean interface.

Guido