Managed Services Engine vs Configuration Service 2.0

Question

What are the capabilites making MSE and CS 2.0 different from each other?

Answer 1

MSE accomplishes load balancing via message routing; different than ConfigService which is point to point; I do not think MSE has built-in ability to manage custom settings (and change dynamically), monitor server/cluster/endpoint status; or have a ConfigWeb-like UI for various other changes such as adding, removing, activating, deactiving endpoints, etc..but MSE is a customizable environment and such features could be added.  Also, no node service, hence less turnkey on config changes synchronized across nodes, ability to synchronize caches (the Node distributed cache service)...etc...

 

The load balancing in Config Service provides a direct point to point mechanism, which will be faster especially for intra-net based scenarios; but router-based load balancing capabilities are attractive for cross service domain (outside of firewall) scenarios; although they will pay perf penalty of another network hop; and if message is cracked full serialization costs at the router.  The two techniques might be combined in an interesting fashion; something I will be looking into for future.

 

Bottom line though....MSE peer nodes (routed destinations from the broker) could implement the config service;...and hence achieve the features COnfig Service provides....any WCF host (IIS or non-IIS) can implement the COnfig Service...

 

-Greg

 

Answer 2

Hi Greg!

 

w.r.t your response , what's a "best" case for using a combination of Config-Svcs and MSE ?

How do you see them co-exist in their present releases, or is some extension required for this to happen.

 

As we know Config-Svcs is perfect for point-to-point integration and MSE for a more loosely-coupled environment.

Both target different goals and achieve them fantastically. But i'm interested in their co-existance, does it make sense or do we need to make a clear choice - in say a case of virtualizing SOA implementation in an org.

 

I mean a perfect scenario would be to use Config-Svcs for intra-dependent services within an enterprise with all the load-balancing & fault-tolerance, and probably virtualize the main service that will be exposed to internet-integration using MSE.

 

I know both are addressing different scenarios, but since you did mention you'd be looking at their co-existance, just curious to know what you have in mind

 

Regards

SKBG

 

Answer 3

Basically I think they can be combined; simply by implementing Config Services within MSE hosts.  The externally-exposed MSE router would then have advantages of endpoint monitoring, config updates, and node notifications to backend available processing hosts to spray requests out to....I have not attempted to do so, but will think about this in coming weeks and try to work out a configuration and see what the benefits are.  If the combination of two has tangible benefits, I will post a paper on this; but will take me some time to fully investigate.

 

-Greg

 

Answer 4

You mean the virtualized-internal-clients i..e dispatchers within the MSE virtual layer?

yes, i guess that's where the integration of config-svcs and MSE has to happen if the MSE dispatchers have to take advantage of config-svcs loadbalanced services. MSE is extendable as is config-svcs, so it should be possible.

Is it complex? I think it will be required to be able to make practical use of both platforms for SOA scenarios. Even with performance overheads, i guess it's worth...to realize true benifits of SOA. If config-svcs hosted services cannot participate in virtualization while still being load-balanced, it will be a handicap. Same way if MSE virtualized services cannot provide active-monitoring of nodes, it will be a limitation. A combination will be great.

 

Its good to be part of the developments in SOA enablement, but wonder why it took this long for microsoft to move up the ladder in this area but it looks promising now with more open-source initiatives from MS.

 

Regards

SKBG

Answer 5

I also wonder the part WS-discovery ( released with .NET 4.0 ) will have to play in this .. From a client side WS-Discovery is very nice eg get me any service which implements ICalculator. The only issue is for performance reasons its not worth changing proxies for each call ,though an automatic refetch based on comms /timeout errors should solve most of these issues .

 

If MSE/config service monitors the services and emits the discovery information based on this, clients can connect to servers as specified. However the configuration is in the server not the client ( which is a IMHO a big plus) it also allows point to point and maybe messaged as a backup .

 

It also worth stating that MSE provides a much more extensive service virtualization.

 

Is it viable ?

 

Client side code should be very thin , if anyone is interested in working with me on something like this let me know.

 

Regards,

 

Ben   

 

Answer 6

Well, as I see, at this point both MSE and Config-Svcs do exactly what they say, MSE is an ideal virtualization platform and Config-Svcs a loca-balancing & fault-tolerant platform for services. MSE doesn't monitor nodes as Greg mentioned and therefore cannot provide a robust load-balanced fault-tolerant environment for service clients. Which is kind of acceptable since it leaves load-balancing to the services themselves. But It provides a good open platform for key features like message routing and transformation and also policy-implementation, key for stepping towards SOA. Config-svcs on the other hand is simply great in terms of load-balancing & faut-tolerance.

 

Scenario in MSE is that we don't necessarily have to own the services being virtualized, they could be remote/partner services. One of the criteria for services to benifit from config-svcs is they have to share their configuration data in a common repositiory, and also implement config-svcs. But ofcourse we could still wrap an external service with config-svcs.

 

I guess Greg is right at pointing out the best place to bring in config-svcs into MSE is where the Router dispatches the messages to the services (internal service client w.r.t MSE) - so have to evaluate how we extend the existing MSE's router implementation.

 

I look forward to any progress on this as it makes a lot of sense.

Regards
Satish

 

Answer 7

"I guess Greg is right at pointing out the best place to bring in config-svcs into MSE is where the Router dispatches the messages to the services (internal service client w.r.t MSE) - so have to evaluate how we extend the existing MSE's router implementation."

I agree with this however if MSE can be extended so it monitors the services (ela config-svcs) and emits WS-Discovery information to contact the services than you will also get point to point and hence not suffer the overhead and performance penalty of the routed message solution.  You can also include a weighting in ws-discovery meta data.  The end result is simple high performance , centrally managed point to point clients where topology allows ( intranets). These clients don't need any connection to a central DB or management service and you can use routed as a backup if you cant get udp through a firewall  or require enhanced security.

Regards,

Ben

Answer 8

Now I understand more about it, Thanks for your effort! It's very valuable.

Answer 9

Take a look at Nevatech Sentinet platform, http://www.nevatech.com. It's an evolution of MSE and CS 2.0 concepts formed into a solid implementation and product. Sentinet is built on WCF 4.0 and WIF and supports all the latest Microsoft stacks as well as Windows Azure platform.