COM+ (Enterprise Services) or Remoting or Web Services (again)?

  • Article

I have addressed this conversation several times, and like others I am blogging my stand so I can just respond to the question with a link to this post from here out.  I am not attempting to define SOA or provide guidance about SOA in this post; this post is more about implementation choices that have (performance, management, deployment, and migration concerns).

Forget what you have heard and what you think.

Use Enterprise Services (ES) internally (inside your own network where you are not restricted by firewall boundaries) for line of business applications.  You do not take the Interop overhead hit that you think you take when you reference a COM component from a .NET assembly.  (Note:  I did not say there is no interop hit; I am simply stating that Enterprise Service interop is not the same thing COM interop with .NET).  It is easy to think COM+ must take the same the interop hit as COM does, this is simply not true.

Why use ES?

  • Management MMC - (security, configuration, monitoring is already built and deployed; don't waste time trying to build and deploying a management interface over .NET remoting, for line of business applications.  The value is of this exercise is questionable).  The ability to manage your components in something besides XML config with notepad is pretty significant for large IT shops. 
  • Best Performance - no questions asked, (forget what you read COM+/ES is the best performing stack in Microsoft today)
  • Reach and deployment - ES is the most mature of all the choices (simple it has been around longer than the other two choices)
  • Indigo - this is big and important.  ES is the best path to Indigo.

Expose your ES with Web Services (when it makes sense to do so)

Write a little ASMX that forwards the call to you ES components (or other services, applications, or integration brokers (like BizTalk).

Yes, you can go into the COM+ explorer and simply check the option to expose your COM+ component over HTTP (or even as a web service with Windows Server 2003).  The benefit of this is the fact you do not have to author the ASMX (or WSDL), just configure an end point URL to IIS.  This allows you to quickly expose your legacy components as services without writing any code (or in the event you do not own the source code).  The disadvantage of using the COM+ explorer to general the WSDL is the RPC encoding style of the web service (same thing you get in the default Web Service template from Visual Studio 2002 an 2003).

Recommendation is to really roll your own ASMX so you can specify doc/literal/bare over the wire (think WS-BasicProfile https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsvcinter/html/wsi-bp_chapter3.asp).  If it is worth the time to build a web service, it is worth the time to make sure it is inteoperable with other clients and services (besides .NET).

Remoting

Hmmm - now your pickings are slim when it comes to the need for remoting in line of business applications.  Remoting has its place and there are a lot of information out there about when to use Remoting.  However the guidance out there does not do a very good job at profiling line of business applications (like the ones you write for an insurance company, bank, hospital or ASP.NET web site).  This is for all who spend time writing line of business applications.  The requirement or the recommendation for making remoting your first or default option should be done with much care, if you are concerned with the entire solution, not just performance, or just management or just deployment, etc., etc. Instead focus on balancing between each of these areas so your application have a good story in most or all of these areas. 

We have taken away the performance argument (by the way performance is many scenarios are really the least of your concerns at this level).  Deployment, maturity, management, security, cross process calls, and migration to Indigo all state the ES is the best choice for striking balance in most line of business applications (just the facts).  I understand there are some remoting fans out there and this post may draw some heat from those remoting fans and those who have been scarred with the nightmares created by MTS/COM+ and VB binary compatibility.

The point of this post is not to put down remoting, but to really put out the rumors around ES and ASMX.  So in conclusion

  • Expose with ASMX Web Services
  • Build internal custom components using Enterprise Services (take this with a grain of salt, you may be using BizTalk or another integration broker instead, that's fine use the best tool for the job).
  • Use remoting if you must, not as the default

Richard Turner does a much better job at digging down into some of the details in his post, so instead of rehashing take look at his post on this topic.  https://blogs.msdn.com/richardt/archive/2004/07/21/190742.aspx.

What about MSMQ?  Out of scope of the purpose of this blog.  If you have questions on this guidance feel free to post a comment and I will respond with a MSMQ post.

Thanks,

 

Ed