This post originated from an RSS feed registered with .NET Buzz
by Robert Hurlbut.
Original Post: Ramblings on Enterprise Services
Feed Title: Robert Hurlbut's .Net Blog
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/rhurlbut/Rss.aspx
Feed Description: Development with .Net, Rotor, Distributed Architectures, Security, Extreme Programming, and Databases
Brian Noyes has posted some great thoughts and arguments for the use of Enterprise Services in your n-tier application.
I am reposting some of my comment here:
Very well done article on ES. If you have read my blog over the past year, I have also been a big supporter and promoter of ES. But, I have also felt the frustration of getting this to work for some of the issues that Indigo will address. Using DCOM with built-in security across two boxes is one of the best transport solutions (performance, security, etc.), much better than WebServices, Remoting, etc. but ES comes with many penalties such as lack of support for all .Net types, problems with .Net security across machine boundaries, difficulties with custom exceptions across machine boundaries, and other headaches with distributed transactions using database vendors other than Microsoft.
Even with the limitations, I completely agree that ES provides the best solution in .Net today for distributed transactions, Windows security across boundaries, asynchronous MSMQ calls, etc. I certainly wouldn't want to roll my own (believe me, I have looked at this as others have, and it is isn't easy).
That's key, isn't it? First, determine the needs of your project. Do you need distributed transactions? Do you need Windows security across machine boundaries? If you can live with the the limitations that Web Services and .Net Remoting provides (i.e. lack of distributed transactions and robust security (without rolling your own) ), then use those methods. But, if you need the services mentioned above without having to write your own, then definitely look at Enterprise Services today.
I especially like Brian's explanation for how Indigo programming will look a lot like ES programming (at least the use of declaritive programming):
But the thing is that the Indigo programming model abstracts away all the web service goo from you and lets you work with a much more clean and declarative model. It happens to have a declarative model that looks much closer to Enterprise Services programming today than it does to web services programming today. Through configuration, you will be able to control the transport layer and make it act like a web service, Enterprise Services, or .NET REmoting under the covers, but your code will look an awful lot like ES code from what I have seen.
I am not sure that gives as strong an argument to use Enterprise Services, but it does point developers to the way they should be thinking and planning now for the move to Indigo in the future. For Indigo, learn how declaritive programming works today. It will pay off.
Previous Topic
