Moving Forward >>> .NET Reality Check
(quoted from http://forums.sgdotnet.org/ShowPost.aspx?PostID=3281)
Hello,
To follow up with my previous email about the deprecation of SOAPFormatter in .NET 2.0, I am wondering how many ppl here uses heavy-duty remoting in their projects. If you are, how are you securing that channel ? Are you using Custom Sinks for that ? Or are you using Enterprise Services ? If you are using Custom Formatters and Sinks, please minimize the use of it as it is NOT a strategic step moving forward.
The reason why i am asking is because Microsoft's focus is on Web services, Remoting is not getting a whole lot of new features going forward. Thus, it is not a long-term strategic technology. The deprecation of SOAPFormatters is just the beginning. To move forward to Indigo which will significantly change a lot of things (for the better...), it will also change the way you look at XML Services. Notice that I dropped the word "Web"...You may also need to change the way you look at communication...such as dumping the mindset of the RPC-ish way of communication, etc...
Indigo is something that has caught my excitment and is probably the only technology in recent years that is worth its money Smile In fact, its the only technology that has got me going for the last few months. It will really open up the way SOAP is supposed to be...and not the SOAP we are seeing today, which offers very little options of MEPs..which is why SOAP is no more an acronym for "Simple Object Access Protocol". In SOAP 1.2, SOAP is just SOAP.
Therefore, shielding your code from specific implementations is of critical importance. I know it is a little bit tough but I recommend against using physical tiers to start with. Use layers - gain maintainability and reuse. But don't use tiers...Try NOT to anyways. Tiers are complex, expensive and slow and may not be as future-proof as you think. Networks deter performance more than you think. In fact, the costs of remoting across multiple machines outweigh the benefits of it.
I took a few tips on moving expectations forward to Indigo. Please ping me if need further clarifications.
1) Use ASMX enhanced with WSE if required. The key word is "If Required" WSE is supported and is the only supported Advanced Web Services Toolkit today. Even IBM's ETK is NOT suppported...However, compatibility is an issue with the different flavours of WSE as the standards are changing too fast today.
By implementing your service in ASMX/WSE, your service will automatically have an explicit boundary, expressed in a standards-based schema, sharing standards-based schematized data documents and will communicate over open standards transports. This cannot be said of ES or Remoting components!
2) Inside my service, I need to spread my implementation across n physical tiers and therefore need to call objects on remote machines.
If you can implement the logic on each of the physical tiers as individual services, do so! By implementing mini-services inside your larger service, you'll be more closely aligning yourself with Microsoft's entire Distributed Applications strategy and will reap great benefits when Indigo is released. And I add that we are NOT talking just about Microsoft, most major technology vendors will have their goals of Distributed Applications very much aligned with each other. The coming of WS-I and the rolling out of WS-BP1.0 is a major milestone to reach there.
3) Operations within my Service involve retrieving, storing and processing high volumes of complex data and requires many traversals between objects.
Consider consolidating the code which performs the highest number of communication traversals on the same physical box to avoid the penalty imposed by traversing the network. Architects and Designers need to take note of that as latency must be kept in check. Play within the sandbox wisely Smile
If you must physically separate components (ie: on separate boxes) which need to exhange large amounts of data or communicate intensively, use .NET Enterprise Services (ES) components on each tier. The reason we opt for ES here is that ES uses DCOM on the wire and is by far the fastest technology on the Microsoft platform for remoting object invocations and data exchanges. Again, consider wrapping access to this portion of your Service with ASMX.
If you call ES components on the local box, consider configuring and activating them as Library (in-process) rather than Server (out-of-process) components wherever possible - especially if you are able to locate all on the same physical box.
4) I need to communicate between two components in different AppDomains inside the same process
This is the second of the two scenarios where .NET Remoting is recommended. Remoting has explicit high-performance support for cross-AppDomain communications. Note that this is only for communications between AppDomains inside the same process. If you have two .NET components that must be hosted in two different processes (on the same machine), I recommend implementing the logic as .NET ES components hosted in COM+...Yes, use DCOM !!!
.NET Remoting is NOT the fastest way to call a remote object! .NET Enterprise Services is! Note that by remote, I mean an object that runs in a process remote from yours ... whether it's on a remote process or a remote machine! Google in MSDN for papers on performance comparisons between these two. I think you will be surprised how Remoting doesnt have much of a performance edge, if at all...
5) I believe that there are recent papers (one is published in .NET Asia) that does some performance comparisons between Binary and SOAP Calls and I think everyone is surprised at how fast SOAP, if designed properly, can be. The architects and the designers have to make their decisions based on their findings. If the interop benefits of SOAP greatly outweighs the performance lags of it (even if it is proven more and more these days), we have to sell the story of being more "future-proof" and "interop-proof".
To summarize, COM / COM+ will not disappear, it will be part of hybrid solutions, and transparent to the service interface.
Remoting is useful for crossing app domains, but not for crossing machine boundaries. Use it for fault tolerance within a process (one app domain goes down, the main process stays alive). Again, I empahsize on the careful design implementations of it. It is NOT that "future-proof" !
Crossing machines and processes, with NO Doubt ! --- DCOM is fastest binary protocol, and can be secured, which means EnterpriseServices (ES). This means and facilitates transactions and guarantees message delivery. Your ES investment with COM+, MSMQ WILL be supported by the world of Indigo.
On ASMX serialization vs. binary serialization with remoting, ASMX will be faster than .NET remoting. I will give a couple of presentations soon on the next generation of XML Serialization in .NET 2.0 explains it all and how performance (SGEN, Decompression on HTTP and TCP, etc) is the key thing the XML Serialization team is working on moving forward in .NET 2.0 to Indigo.
Do take note that short term performance gains using remoting today will not position your applications for future releases (I.e., Indigo). Like I said above, you can expect better performance with ASMX in future as programming models change, and usually what impacts performance most is usually bad architecture, including hardware choices, physical tier distribution and bad designs that are NOT well thought of. Some issues that I have come across are the use of Datasets (a NO ! NO ! in distributed designs -- > Interop is a big problem and Datasets are TOO verbose), the inclusions of Data Schemas at the wire level when traversing network calls, etc. One thing that will also support performance improvement at a more granular level is also XML parsers…There are better and more efficient XML Writers and Readers coming up, something the same XML Messaging and Serialization team is working on.
How many WS* protocols do we need? Less. SOAP/XML is a great start. WS-Security is critical for end to end message integrity. We need standard protocols for interoperability, thus we need tools to assist with serialization, such as WSE 2.0.
WSE 2.0 gives us a chance to work with WS* protocols now, while waiting for Indigo. The important thing is to realize it is taking you in the right direction. These standards move fast, so does the WSE team. Indigo will just swallow it all making it even easier once standards are more stable.
Thank you.
~Softwaremaker (BLOG)
M. Twain: "I didn't have time to write a short letter, so I wrote a long one instead"
Hello,
To follow up with my previous email about the deprecation of SOAPFormatter in .NET 2.0, I am wondering how many ppl here uses heavy-duty remoting in their projects. If you are, how are you securing that channel ? Are you using Custom Sinks for that ? Or are you using Enterprise Services ? If you are using Custom Formatters and Sinks, please minimize the use of it as it is NOT a strategic step moving forward.
The reason why i am asking is because Microsoft's focus is on Web services, Remoting is not getting a whole lot of new features going forward. Thus, it is not a long-term strategic technology. The deprecation of SOAPFormatters is just the beginning. To move forward to Indigo which will significantly change a lot of things (for the better...), it will also change the way you look at XML Services. Notice that I dropped the word "Web"...You may also need to change the way you look at communication...such as dumping the mindset of the RPC-ish way of communication, etc...
Indigo is something that has caught my excitment and is probably the only technology in recent years that is worth its money Smile In fact, its the only technology that has got me going for the last few months. It will really open up the way SOAP is supposed to be...and not the SOAP we are seeing today, which offers very little options of MEPs..which is why SOAP is no more an acronym for "Simple Object Access Protocol". In SOAP 1.2, SOAP is just SOAP.
Therefore, shielding your code from specific implementations is of critical importance. I know it is a little bit tough but I recommend against using physical tiers to start with. Use layers - gain maintainability and reuse. But don't use tiers...Try NOT to anyways. Tiers are complex, expensive and slow and may not be as future-proof as you think. Networks deter performance more than you think. In fact, the costs of remoting across multiple machines outweigh the benefits of it.
I took a few tips on moving expectations forward to Indigo. Please ping me if need further clarifications.
1) Use ASMX enhanced with WSE if required. The key word is "If Required" WSE is supported and is the only supported Advanced Web Services Toolkit today. Even IBM's ETK is NOT suppported...However, compatibility is an issue with the different flavours of WSE as the standards are changing too fast today.
By implementing your service in ASMX/WSE, your service will automatically have an explicit boundary, expressed in a standards-based schema, sharing standards-based schematized data documents and will communicate over open standards transports. This cannot be said of ES or Remoting components!
2) Inside my service, I need to spread my implementation across n physical tiers and therefore need to call objects on remote machines.
If you can implement the logic on each of the physical tiers as individual services, do so! By implementing mini-services inside your larger service, you'll be more closely aligning yourself with Microsoft's entire Distributed Applications strategy and will reap great benefits when Indigo is released. And I add that we are NOT talking just about Microsoft, most major technology vendors will have their goals of Distributed Applications very much aligned with each other. The coming of WS-I and the rolling out of WS-BP1.0 is a major milestone to reach there.
3) Operations within my Service involve retrieving, storing and processing high volumes of complex data and requires many traversals between objects.
Consider consolidating the code which performs the highest number of communication traversals on the same physical box to avoid the penalty imposed by traversing the network. Architects and Designers need to take note of that as latency must be kept in check. Play within the sandbox wisely Smile
If you must physically separate components (ie: on separate boxes) which need to exhange large amounts of data or communicate intensively, use .NET Enterprise Services (ES) components on each tier. The reason we opt for ES here is that ES uses DCOM on the wire and is by far the fastest technology on the Microsoft platform for remoting object invocations and data exchanges. Again, consider wrapping access to this portion of your Service with ASMX.
If you call ES components on the local box, consider configuring and activating them as Library (in-process) rather than Server (out-of-process) components wherever possible - especially if you are able to locate all on the same physical box.
4) I need to communicate between two components in different AppDomains inside the same process
This is the second of the two scenarios where .NET Remoting is recommended. Remoting has explicit high-performance support for cross-AppDomain communications. Note that this is only for communications between AppDomains inside the same process. If you have two .NET components that must be hosted in two different processes (on the same machine), I recommend implementing the logic as .NET ES components hosted in COM+...Yes, use DCOM !!!
.NET Remoting is NOT the fastest way to call a remote object! .NET Enterprise Services is! Note that by remote, I mean an object that runs in a process remote from yours ... whether it's on a remote process or a remote machine! Google in MSDN for papers on performance comparisons between these two. I think you will be surprised how Remoting doesnt have much of a performance edge, if at all...
5) I believe that there are recent papers (one is published in .NET Asia) that does some performance comparisons between Binary and SOAP Calls and I think everyone is surprised at how fast SOAP, if designed properly, can be. The architects and the designers have to make their decisions based on their findings. If the interop benefits of SOAP greatly outweighs the performance lags of it (even if it is proven more and more these days), we have to sell the story of being more "future-proof" and "interop-proof".
To summarize, COM / COM+ will not disappear, it will be part of hybrid solutions, and transparent to the service interface.
Remoting is useful for crossing app domains, but not for crossing machine boundaries. Use it for fault tolerance within a process (one app domain goes down, the main process stays alive). Again, I empahsize on the careful design implementations of it. It is NOT that "future-proof" !
Crossing machines and processes, with NO Doubt ! --- DCOM is fastest binary protocol, and can be secured, which means EnterpriseServices (ES). This means and facilitates transactions and guarantees message delivery. Your ES investment with COM+, MSMQ WILL be supported by the world of Indigo.
On ASMX serialization vs. binary serialization with remoting, ASMX will be faster than .NET remoting. I will give a couple of presentations soon on the next generation of XML Serialization in .NET 2.0 explains it all and how performance (SGEN, Decompression on HTTP and TCP, etc) is the key thing the XML Serialization team is working on moving forward in .NET 2.0 to Indigo.
Do take note that short term performance gains using remoting today will not position your applications for future releases (I.e., Indigo). Like I said above, you can expect better performance with ASMX in future as programming models change, and usually what impacts performance most is usually bad architecture, including hardware choices, physical tier distribution and bad designs that are NOT well thought of. Some issues that I have come across are the use of Datasets (a NO ! NO ! in distributed designs -- > Interop is a big problem and Datasets are TOO verbose), the inclusions of Data Schemas at the wire level when traversing network calls, etc. One thing that will also support performance improvement at a more granular level is also XML parsers…There are better and more efficient XML Writers and Readers coming up, something the same XML Messaging and Serialization team is working on.
How many WS* protocols do we need? Less. SOAP/XML is a great start. WS-Security is critical for end to end message integrity. We need standard protocols for interoperability, thus we need tools to assist with serialization, such as WSE 2.0.
WSE 2.0 gives us a chance to work with WS* protocols now, while waiting for Indigo. The important thing is to realize it is taking you in the right direction. These standards move fast, so does the WSE team. Indigo will just swallow it all making it even easier once standards are more stable.
Thank you.
~Softwaremaker (BLOG)
M. Twain: "I didn't have time to write a short letter, so I wrote a long one instead"
Comments