Dynamic binding is a topic that seems key in Service Oriented Architectures, since it provides a form of decoupling between service requesters and service providers. The idea is that the service requester is dynamically bound to the service endpoint.

Dynamic binding can take many forms:

1. The data upon which the binding takes place can vary.
a. In the most simple form the logical name of the service is translated to the physical address of the service endpoint.
b. A more elaborate form is content-_base_d routing: _base_d upon the contents of the service invocation message the service endpoint is determined.
c. Another form is policy-_base_d routing, where the Quality of Service required by the service requester is the criterion _base_d upon which a service endpoint is selected.

2. The component that performs the binding can vary: either the service requester or an intermediary.
a. In case the service requester performs the dynamic binding, it actively queries a service registry, selects the appropriate endpoint and invokes the service.
b. If an intermediary such as a message broker performs the dynamic binding, the service requester only needs to send the message to the intermediary.

3. The technology used for the service registry can vary.
a. You can build your own lookup table with mappings from logical names to physical addresses.
b. You can using the naming service provided by the implementation technology such as JNDI in a Java environment.
c. You can use a UDDI.
d. You can use some other registry product.

It would be a good idea to start sharing experiences with respect to dynamic binding. Do you use dynamic binding? Which of the forms of dynamic binding do you use? What are best practices? What have we learned so far?

My experience is that organisations are not very often have very simple dynamic binding mechanisms in place, or do not use dynamic binding at all. An example of the latter is where WSDL files are put on a central web server and binding takes place during development. My current client performs dynamic binding in a message broker, that uses a custom lookup table to map technical service names to service endpoints which are all provided through WebSphere MQ. Also, the content-_base_d routing facilities of the message broker are used.

Regards,
Danny Greefhorst

Danny,

After reading this I would like to add two points.

First I would like to add another form to the three forms of dynamic binding you mention. Binding also occurs at the protocol level. On the web often we use the implicit HTTP protocol to communicate in a REST (1) like fashion. When we build applications we bind more explicit to protocols like MQ, JMS or SOAP.

Second, I would like to add something on the Message Broker. In the last years we more and more are adding routing in message broker like architectures. We say that applications shouldn't need to know the details of the systems they are connecting to. I agree that this provides flexibility but it worries me that al routing information is centralised at one point:

• a. After the centralisation of routing it is easy (as you describe in form 1) to add content _base_d routing. But the difference between content _base_d routing and business logic is small and easy to oversee or mistaken.
  My worry is that these centralised message brokers become the monolithic main_frame_ solutions we've just abandoned.


• b. If all logic is bound to one message broker is that dynamic binding or single binding?
  My worry is that all logic is bound to one message broker and that replacing that message broker will be very hard because business logic is not written to consider the message broker as a variable, because there is only one message broker.

Formulated as a design pattern I would advocate for a more synaptic /brain like working vision on the message broker. Instead of one all-knowing message broker I rather use a set of Domain Oriented Message Brokers. Each message broker contains (content) routing for a specific business domain. I think of typically 4-6 message brokers in an enterprise. Message brokers communicate with each other on cross domain issues. This at least prevents a monolithic solution and shows application builders that a message broker is a variable and not a constant.

Cheers,
Ronald Streekstra

@1: Representational State Transfer

Ronald,

I fully agree with you that centralised message brokering is not the answer to dynamic binding. My current client has around 2000 message broker flows defined, and this is becoming a real maintenance issue. I would even go further than stating that there is not one central message broker: I do not think any message broker should be a mandatory intermediary in communications. Message brokering is only usefull when transformations to legacy applications or platforms is necessary. All other communication could just use point-point communication, where the requester simply uses the interface of the service provider. The only mandatory requirement would be that all service information is published centrally, for management and reuse purposes. Although I would like to add dynamic binding _base_d on a central naming service as an additional requirement, I am not yet convinced that this requirement solves day-to-day issues. Any insights into this are appreciated.

With respect to your addition on dynamic binding; protocol binding is yet another dimension, that is sometimes combined with binding to an address _base_d on a logical name (also called naming). For example you could find an HTTP _base_d endpoint in your UDDI for a service, but also an endpoint that is _base_d on JMS. For other technologies (e.g. CosNaming) the protocol is always identical.

Regards,
Danny Greefhorst