Monday, June 21, 2010

Is Dynamic Endpoint Selection practical?

The concept of dynamic endpoint selection sounds really neat. At service runtime, the service consumer need not know what service is going to be invoked to fullfill its invocation request; rather, a SOA governance tool can help faciliate this decision of choosing a providing service, based on the pre-defined contractual functionality, interface, SLA, and policy. The SOA governance tool will choose the best service to invoke to accomplish the consumer's requests, bind the consumer to the provider, and complete the "transaction". This sounds super helpful and a bit optimistic, but is it practical? In other words, Are there really architectures using this approach of having services "swap in and swap out" at runtime according to the consumer's needs? I've only had 1 customer to date consider this feature of SOA, as most don't have a complex enough requirement to justify the feature in the architecture. A couple things come to mind when thinking about this capability:

-- Dynamic Endpoint Selection is probably most applicable with external hosted services, outside your corporate firewall. For example, if I need to get a stock quote or a weather service, I probably have less concern about who the Provider is, as long as my Quality of Service (QoS) needs are met. Just get me the info! However, internally hosted services won't have backups that applicable to my business. Getting customer or Supply Chain information that is specific to my business is impossible to replicate externally, or is just questionable architecture if it is redundant internally (putting failover and D/R aside).

-- This could work well in a B2B scenario or for a multi-agency government scenario. This is better known as a Community Cloud. If one provider can not provide a consumer the information needed at the time the consumer needs it, another provider can "step in" and fullfill the request. In a community, a lot of the participants have access to same or similiar information sources.

-- This could be really nice to automate a B2C retail online transaction. I don't need to know who the merchant is selling the product, just the price and terms. In Amazon, we get presented with a checkout to a specific merchant. What if I don't ever need to know who the merchant is until after purchase (like Rather, a service does the dynamic selection. This would assume vendors have connected their inventory systems into the marketplace for an automated inventory check before purchase order completes. Still, today's buyer is normally accustomed to know who they are buying a product from before the committ to purchase. Part of this is brand identify, part educated consumer, and part skepticism with all the horror stories of purchasing products over the Internet.

-- Creating the general interface contract and getting proper provider compliance can be cumbersome. Does the end justify the means? How many consumers will use this approach, if the investment is put up from the providers?


  1. Jordan,
    I think you are right on with this usage, can't say that I see a lot practical examples of this in the in house IT space.


  2. Although I understand what you are saying combining dynamic endpoints with business rules for example has a lot of power. For industries where laws keep changing (i.e. the implementation) but not the contract (binding or data) this would be very useful. For an example please see my blog here: