Static Functions

[acbell]

Hi,

Am I missing something obvious, or is there no support for static or class functions? If this is indeed the case, I've got two questions:

1) Why?
2) Do you have suggestions on _clean_ bootstrapping to obtain object references?

Thanks in advance,

-- Andrew Bell
andrew.bell.ia@gmail.com

[michi]

I take it that you mean static functions for Slice definitions? If so, they really don't make any sense. After all, a static function, by definition, does not have a target object. As a result, a static function will always be executed locally and cannot possibly go remote. It follows that static functions have no place in Slice.

To bootstrap, all you need to do is create one proxy. You can either create a direct proxy, which contains the domain name (or IP address) of the server, plus an object identity, or, if you use IcePack, you can create an indirect proxy, which contains an adapter name. Conceptually, that's quite similar to the idea of corbaloc and corbaname object references. Once you have access to the initial object, you get more proxies by invoking operations.

Note that, contrary to CORBA, Ice doesn't need a naming service. That's because Ice proxies are not opaque, whereas CORBA object references are. In fact, the only reason for the existence of a naming service is this silly notion that object references must be opaque. (But of course, that notion is then promptly destroyed by the existence of corbaloc and corbaname.) The resulting architecture is a mess and results in applications that more prone to failure and have more dependencies than necessary.

Cheers,

Michi.

[acbell]

I take it that you mean static functions for Slice definitions? If so, they really don't make any sense. After all, a static function, by definition, does not have a target object.

Suppose you have a class (call it Car, for the sake of discussion). What if your Car class on the server contains a static list of all the cars that exist? You might want to retrieve that list on the client. Without some way to make a remote call without a Car instance, you have to contrive another class to return you a list of cars. Of course, you can contrive a dummy Car, but that is ugly and can force you to code exception cases (the list of cars contains all of the cars but my dummy car, etc.).

Do you have other suggestions for handling such a case?

[marc]

Static functions have no place in distributed systems. Consider two Car proxies, that point to Ice objects implemented by the same physical server. A static function means that if you call on either of the two proxies, you get the same response, since both Car implementations operate on the same static class data.

Now consider that the server is redeployed, and the two Car Ice objects are moved to different physical servers. Such a change must be transparent to the client. However, with static functions, such transparency is lost: If you call on the two proxies, you now get different results, because each proxy points to a different server that operates on different static class data.

Static functions also destroy language transparency. Given a Slice-defined interface Car, implementations can be written in C++, Java, or any other supported language, regardless of the programming language used for the client. But you cannot support static functions across different languages. So if you have some Cars implemented in Java and others in C++, you again cannot have all implementations return the same results for the same static function calls.

In any case, the solution to the problem is simple: Define a singleton class such as CarInventory, that holds a list of proxies for all Cars. Instantiate only one single Ice object for CarInventory. Then your clients can access this CarInventory Ice object and get a list of all Cars, regardless of where or how the individual Cars are implemented.

[acbell]

What you are implying, I think, is that server-side static data is a bad thing. Perahps if you have implementations on various servers or across various languages, it is (though syncronizing server data is not always unreasonable).

Still, I would bet that a system with a single server written in one language is the norm, not the exception. In such an enviornment, static data (and hence functions) make a lot of sense - it's just like you were writing a single application, where you have farmed out some of the work.

I just think it would be incredibly convenient for the system to create a "default" proxy which isn't bound to an implementation object for each class that had a "static" function. This would eliminate the singleton class on both the client and server that serves no purpose than to transport the static data. If you have a truly distributed server implementation then you always have the option NOT to use the static data, but it would simplify things for the rest of us.

Cheers,

-- Andrew Bell
andrew.bell.ia@gmail.com

[marc]

I do not imply that server-side static data is always a bad thing. This is a valid implementation choice for some designs. Ice separates implementation from interface, and for the reasons I outlined, static member functions have no place in a Slice interface definition. However, you can implement an interface defined in Slice as a singleton that accesses static server data.