As I understand it, the MSE allows you to define an endpoint (hosted in the runtime) and declare some operations (web methods) on that endpoint. Then you can map those operations to physical service methods that were imported (or defined manually). This
is a very powerful notion: customizing the contract in order to minimize the coupling between consumer and service and thus allowing for easier and independent version management of both consumer and service. (I hope I got it right ;-)
The BizTalk LOB adapter framework, takes this even one step further. It allows the consumer to select the operations (web methods) to use of a service and couple with only those methods. This is even more fine grained than what the MSE does. Here each individual
consumer gets its own custom contract (which is always a sub-set of the entire service contract, of course).
Now here's my question: What do you think of this Consumer Driven Contract idea for the MSE? And how would you propose to build this with the current MSE 6.2 version?
Another -hopefully related- issue is consumer tracking. The technical docs talk about taking services offline when all consumers have upgraded to newer versions. But I could not find any means by which you could detect that in the MSE. I would say you need
a registry that contains all dependencies on each service in order to be able to detect that all consumers are gone from a service. Of course this would require that consumers of a service are also registered, for which no technology is available today AFAIK.
How would you propose to keep track of MSE service consumers?
Nov 15, 2007 at 4:18 PM
We actually developed a prototype Web UI for a customer that allowed consumers to specify which exact operations they wanted to consume through their own custom endpoint. It used the Service Catalog functions to define the appropriate meta data for their
"personalized" services so you could certainly build your own tool to achieve this result. What the exercise exposed was the sophisticated provisioning that was required to support that role in a real-world scenario, which scared the customer off that approach.
However, I think that is definitely a direction organizations will go with this level of agility.
That does lead to the second issue, operation/service provisioning. Many organizations today use anonymous or the "single credential" security model for of their services. To provide sufficient visibility, you really have to log who is using which operations.
We do this today through logging and/or BAM. However, even the built in perf counters will show you operation version usage on an anonymous level. Either approach will provide you with some level of visibility to make a decision on when you can retire operations.
BTW, at the end of the day, the most important component to retire is the implementation and there are lots of strategies for doing that - one of which we demonstrated in the walk through. "Retiring" meta data can help you maintain a cleaner service model,
but doesn't really impact the efficiency of the system or the overall cost of the system.