The very idea of having different bindings is based on the fact that they allow different optimizations. Working over the Internet, over a LAN, or directly against a database each places very different demands on the communication protocol. For example, one could imagine a browser written for mobile phones that uses WAP, or another browser running in contact with your company database using database routines directly. With the data format independent specification in place, we are free to translate it into different formats. What is defined here is the canonical bindings using several formats, but by no means the only one possible. Also, one browser can support several of these bindings simultaneously, which is also true of the databases. So, our goals for each binding are the following:
The binding should be as natural and clean as possible. It should not try to solve problems that the format is not well adjusted to solve. For example, the CORBA binding will have performance problems when used over the Internet, and should not try to solve these. Therefore, each binding should have a well-defined domain of optimal use.
On the other hand, the binding should try to use the particularities of the technology used to allow optimizations within the domain of optimal use.
As each binding defines a communication protocol, the design is expected to add, to the component representation, a layer that defines the capabilities with respect to editing and storing of changes.
A binding should also define the possible means of locating the component, so that given the binding and a URI locating the component, it is clear how to access it.