An important part of the ‘publish – find – bind model’ and hence also of a SOA is service binding. It is the way in which instances of services are incorporated and bound to applications. This binding can occur either at development-time or at runtime [KRA07]. 

For development-time binding the developer looks in the service repository for a service. Assuming that he finds the right service, a full description of the service can be retrieved from the service contract. Using this information the developer can implement a client (i.e. an application frontend) which uses a service stub in order to invoke the service. This type of binding is relatively simple compared to runtime binding but sufficient for most scenarios, though. 

In general runtime binding is more complex because not all details about the service are known at design time. Therefore, mechanisms have to be implemented to allow dynamic binding. One example is to allow binding to different services which all provide the same functionality and have the same interface but a different name. This brings the advantage that the service definition is already known at development time, only the name and the physical address of the service changes. This scenario is also possible based on services with equal properties instead of special names. In both cases the client is limited to services which provide the same functionality and makes its choice based on specific names or equal properties. Although it adds the flexibility of being able to use different services, it is of limited power because all services provide the same functionality.  

Runtime service discovery based on reflection is needed if no details about the service definition at all are known at development time. In order to be able to bind in this case, some kind of reflection mechanism which discovers the semantics of services and is able to build a valid request has to be available. Because of its complexity the latter one is only very rarely used [KRA07].