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